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ABSTRACT 


Declining  budgets  and  the  reduction  of  workforce  has  caused  many  organizations 
to  perform  additional  job  assignments  with  fewer  personnel.  These  organizations 
realized  that  in  order  to  survive  in  a  competitive  market,  scarce  resources  would  provide 
the  most  value  if  used  to  work  on  mission-essential  tasks,  while  allowing  the  perfonnance 
of  support  functions  by  an  outside  source  (called  outsourcing).  The  Department  of  the 
Navy  (DoN)  is  one  organization  that  has  chosen  to  outsource  many  business  areas,  but 
none  bigger  than  the  outsourcing  of  information  technology  (IT)  to  form  the  Navy 
Marine  Corps  Intranet  (NMCI) — the  largest  IT  outsourcing  contract  to  date. 

While  the  DoN  has  faced  many  challenges  since  the  onset  of  the  NMCI 
contracting  agreement,  this  thesis  focuses  on  the  challenges  faced  by  the  Navy  Reserve 
with  managing  the  Intranet’s  user  accounts.  The  research  uses  the  principles  of  Business 
Process  Redesign  (BPR)  and  Knowledge  Management  (KM)  to  detennine  the  current 
state  (As-Is)  and  to  recommend  changes  in  the  account  management  process. 
Specifically,  the  Knowledge- Value  Added  (KVA)  methodology  was  used  to  determine 
the  amount  of  knowledge  quantitatively  embedded  in  each  sub-process  for  a  relative 
comparison  of  the  value  that  the  sub-processes  provide  to  the  overall  process. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  PURPOSE . 1 

B.  BACKGROUND . 1 

C.  RESEARCH  QUESTIONS . 2 

1.  Primary  Research  Question . 2 

2.  Secondary  Research  Questions . 3 

D.  SCOPE  AND  LIMITATIONS . 3 

E.  METHODOLOGY . 3 

F.  BENEFITS  OF  THE  RESEARCH . 4 

G.  ORGANIZATION  OF  THE  THESIS . 5 

II.  NMCI  HISTORY  AND  THE  ASSOCIATED  BENEFITS . 7 

A.  INTRODUCTION . 7 

B.  DRIVING  FACTORS  FOR  THE  NEED  TO  CHANGE . 7 

C.  NAVY  MARINE  CORPS  INTRANET  (NMCI) . 8 

D.  EXPECTED  BENEFITS  OF  NMCI . 9 

E.  CHAPTER  SUMMARY . 11 

III.  THE  ACCOUNT  MANAGEMENT  CHALLENGE . 13 

A.  INTRODUCTION . 13 

B.  THE  CHALLENGE  IN  ORGANIZATIONAL  STRUCTURE . 14 

C.  COMMAND  MANAGEMENT . 16 

1.  Duplicate  Accounts . 17 

2.  Multiple  Accounts . 20 

3.  Inactive  or  Unused  Accounts . 20 

4.  Excessive  Move,  Add,  Change  Request . 21 

5.  Multiple  Stove-Piped  IT  Systems . 22 

D.  CHAPTER  SUMMARY . 25 

IV.  THE  CURRENT  PROCESS  OF  ACCOUNT  MANAGEMENT . 27 

A.  INTRODUCTION . 27 

B.  KNOWLEDGE  MANAGEMENT . 27 

1.  Knowledge  in  the  Context  of  Knowledge  Management . 29 

2.  The  Role  of  Information  Technology  in  Knowledge 

Management . 32 

C.  KNOWLEDGE- VALUE  ADDED . 34 

1.  KVA  Theory . 35 

2.  How  KVA  Works . 36 

3.  Return  on  Knowledge . 38 

D.  BUSINESS  PROCESS  REDESIGN . 39 

1.  BPR  Defined . 40 

2.  The  Use  of  IT  and  BPR . 41 

3.  Phases  of  BPR . 42 

vii 


E.  DEFINING  THE  CURRENT  PROCESS  FOR  ACCOUNT 


MANAGEMENT . 44 

1.  Data  Collection . 45 

2.  Collection  Methodology . 45 

3.  The  AS-IS  Process . 47 

F.  “AS-IS”  PROCESS  FLOWCHARTS . 48 

1.  Scenario  1 . 48 

2.  Scenario  2 . 50 

3.  Scenario  3 . 51 

4.  Scenario  4 . 52 

a.  Accounts . 52 

b.  Seats . 52 

G.  KNOWLEDGE  VALUE  ADDED  IN  AN  NMCI  ENVIRONMENT . 53 

1.  Time  Required  to  Learn  a  Process . 53 

2.  KVA  Calculations . 54 

a.  Assumptions . 54 

3.  Metrics . 56 

4.  Analysis  of  Results . 57 

H.  “TO-BE”  PROCESS  FLOWCHARTS . 60 

1.  Scenario  1 . 60 

2.  Scenario  2 . 62 

3.  Scenario  3 . 63 

4.  Scenario  4 . 63 

a.  Accounts . 64 

b.  Seats . 64 

5.  Data  Analysis  Comparison . 64 

I.  CHAPTER  SUMMARY . 67 

V.  INDUSTRY  STANDARDS  FOR  OUTSOURCING  AND  COMMERCIAL- 

OFF-THE-  SHELF  MANAGEMENT  TOOLS . 69 

A.  INTRODUCTION . 69 

B.  INFORMATION  TECHNOLOGY  OUTSOURCING  BEST 

PRACTICES . 69 

1.  Four  Phases  of  Strategic  Outsourcing . 70 

a.  Phase  1:  Sourcing  Strategy. . 70 

b.  Phase  2:  Evaluation  and  Selection . 71 

c.  Phase  3:  Contact  Development. . 72 

d.  Phase  4:  Outsourcing  Management. . 73 

2.  Benchmarking . 74 

3.  Service-Level  Agreements . 76 

4.  Successful  Organizational  Outsourcing  Engagements . 80 

a.  City  of  Chicago  Partner  with  Unisys  and  Acxiom . 80 

b.  Nike  Partner  with  Lockheed  Martin . 82 

C.  COMMERCIAL-OFF-THE-SHELF  APPLICATION  ANALYSIS . 83 

1.  Overview  of  Identity  and  Access  Management . 84 

2.  Identity  and  Access  Management  Tools . 84 


viii 


D.  CONCLUSION . 86 

VI.  CONCLUSION  AND  RECOMMENDATION . 89 

A.  INTRODUCTION . 89 

B.  RESEARCH  QUESTIONS . 89 

1.  Primary  Research  Question . 89 

a.  How  Might  the  U.S.  Navy  Reserve  Component  (USN  RC) 

Effectively  Manage  Accounts  in  the  NMCI  Environment?  ..89 

2.  Secondary  Research  Questions . 90 

a.  How  Were  the  Accounts  Allocated  during  NMCI 

Deployment? . 90 

b.  How  Are  the  USN  RC  Customer  Technical 

Representatives  (CTRs)  Currently  Tracking  NMCI 
Accounts  per  Region? . 91 

c.  How  is  the  Navy  Reserve  Forces  Command  Currently 

Managing  NMCI  Accounts  for  the  USN  RC? . 92 

d.  How  is  the  U.S.  Navy  Active  Component  (USN  AC) 

Currently  Managing  NMCI  Accounts? . 92 

e.  How  are  Some  of  the  Large  Commercial  Companies, 

which  Have  Adopted  the  Seat  Management  Concept, 
Successfully  Managing  Accounts  across  an  Enterprise 
Solution?. . 92 

f.  What  are  the  ‘Best-Of-Breed’  COTS  Products  Used  by 

Industry  for  Account  Management? . 93 

C.  RECOMMENDATIONS . 93 

1.  The  Proposed  ‘Radical’  Solution . 93 

D.  CONCLUSION . 97 


APPENDIX  A.  CONTRACT  LINE  ITEM  (CLIN)  LIST . 101 

APPENDIX  B.  NMCI  ACCOUNT  MANAGEMENT  SURVEY  QUESTIONS . 107 

APPENDIX  C.  INTEGRATED  WEB-BASED  ENTERPRISE  TOOL  PROTOTYPE  113 

A.  DATABASE  SCHEMA . 115 

B.  PORTAL  LOGIN  PAGE . 116 

C.  PORTAL  PAGE  ONE . 117 


APPENDIX  D.  ENTERPRISE-LEVEL  INFORMATION  TECHNOLOGY 


SOLUTION  FUNCTIONAL  REQUIREMENTS  DOCUMENT . 119 

APPENDIX  E.  WEB-BASED  PROTOTYPE  DESIGN  DOCUMENT  OF 
FUNCTIONAL  REQUIREMENTS . 149 

LIST  OF  REFERENCES . 193 


INITIAL  DISTRIBUTION  LIST 


197 


IX 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


x 


LIST  OF  FIGURES 


Figure  1 .  Duplicate  Account  Creation  Example  1 . 18 

Figure  2.  Duplicate  Account  Creation  Example  2 . 19 

Figure  3.  Draft  NMCI  Instruction . 21 

Figure  4.  NMCI  Enterprise  Took  Web  Portal . 23 

Figure  5.  eMarketplace  Website . 24 

Figure  6.  Service  Request  Electronic  Fonn  Web  Portal . 24 

Figure  7.  Fundamental  Assumption  of  KVA  (From:  Ref.  13) . 36 

Figure  8.  Three  Approaches  to  KVA  (From:  Ref.  14) . 37 

Figure  9.  The  Leavitt  Diamond . 42 

Figure  10.  Phases  of  Business  Process  Redesign  (From:  Ref.  22) . 44 

Figure  1 1 .  As-Is  Flowchart  When  a  New  DRILLRES/FTS  Reports  for  Duty . 48 

Figure  12.  As-Is  Flowchart  When  an  FTS/DRILLRES  Transfers . 50 

Figure  13.  As-Is  Flowchart  When  an  FTS/DRILLRES  Retires . 51 

Figure  14.  As-Is  Flowchart  for  Allocation  of  Accounts  and  Seat  Management . 52 

Figure  15.  KVA  Total  Benefits  Calculation  Example . 55 

Figure  16.  KVA  Total  Costs  Calculation  Example . 56 

Figure  17.  KVA  As-Is  Analysis . 58 

Figure  18.  To-Be  Flowchart  When  a  New  DRILLRES/FTS  Reports  for  Duty . 60 

Figure  19.  To-Be  Flowchart  When  an  FTS/DRILLRES  Transfers . 62 

Figure  20.  To-Be  Flowchart  When  an  FTS/DRILLRES  Transfers . 63 

Figure  2 1 .  To-Be  Flowchart  for  Allocation  of  Accounts  and  Seat  Management . 63 

Figure  22.  KVA  To-Be  Analysis . 67 

Figure  23.  Strategic  Sourcing  Process  (From:  Ref.  26) . 70 

Figure  24.  Phase  1:  Sourcing  Strategy  (From:  Ref.  26) . 71 

Figure  25.  Phase  2:  Evaluation  and  Selection  (From:  Ref.  26) . 72 

Figure  26.  Phase  3:  Contact  Development  (From:  Ref.  26) . 73 

Figure  27.  Phase  4:  Sourcing  Management  (From:  Ref.  26) . 74 

Figure  28.  Radical  Process  Flowchart . 96 

Figure  29.  Radical  KVA  Spreadsheet . 97 


xi 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


LIST  OF  TABLES 


Table  1.  Key  Phases  and  Activities  in  BPR  (From:  Ref.  22) . 43 

Table  2.  Service-Level  Examples  (From:  Ref.  26) . 80 

xiii 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xiv 


GLOSSARY  OF  TERMS  AND  DEFINITIONS 


Account  -  Capability  to  provide  a  person  or  function  access  to  the  NMCI  Network  and 
services  and  is  chargeable  against  the  ledger. 

Account  ledger  -  Accounting  system  that  provides  the  capability  to  track  every  individual 
account  status  and  corresponding  digital  identity. 

Active  Account  -  an  account  that  has  registered  signs  of  activity  and  is  also  chargeable. 

Active  Directory1  -  A  central  component  of  the  Windows  platfonn,  Active  Directory 
directory  service  provides  the  means  to  manage  the  identities  and  relationships  that  make 
up  network  environments.  It  is  a  centralized  and  standardized  system  that  automates 
network  management  of  user  data,  security,  and  distributed  resources,  and  enables 
interoperation  with  other  directories. 

Chargeable  Account  -  NMCI  account  that  is  actively  used  by  individual  or  in  a  functional 
role  including  e-mail  and  access  to  NMCI  resources. 

Claimant  -  a  claimant  denotes  the  next  level  of  management  below  the  Chief  of  Naval 
Operations  headquarters  staff  within  the  budget  arena.  In  the  Navy’s  tradition  of 
relatively  decentralized  management,  the  major  claimants  are  the  focal  point  for 
executing  the  Strategic  Sourcing  Program. 

Contract  Line  Item  0024  (CLIN  0024)  -  an  additional  non-classified  account  that 
provides  a  user  account  in  addition  to  those  provided  with  ordered  data  seat(s). 

Contract  Line  Item  0026AL  (CLIN  0026AL)2  -  an  NMCI  contract  item  referred  to  as  a 
Move  Add  Change  (MAC).  A  MAC  is  an  administrative  logical  change  to  a  user  account 
not  associated  with  provisioning  of  an  ordered  Contract  Line  Item  (CLIN).  They  are 
separated  into  three  categories  with  some  chargeable  and  some  non-chargeable. 

Deactivated  -  An  account  where  access  to  NMCI  is  no  longer  permitted  but  the  digital 
identity  and  flat  name  space  is  retained  for  future  use  on  NMCI . 

Deleted  -  Account  completely  deleted  from  NMCI. 

Disabled  -  An  account  that  is  not  accessible  and  all  e-mail  is  rejected. 


1  Information  obtained  from  the  following  websites  (Accessed  April  2005): 
http://www. google. com/search?hl=en&lr=&oi=definore&q=defme:Active+Directory  ; 
http://www.microsoft.com/windowsserver2003/technologies/directorv/activedirectory/default.mspx 

2  Information  from  the  NMCI  website  (Accessed  April  2005): 
http://www.nmci.navv.mil/Primary  Areas/Contract/Content/Files/Contract  Artifacts/Conformed  Contract/ 

N00024-00-D-6000  Attachl-P00129.pdf 
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Echelon  -  An  Echelon  is  a  Civil  War  term  used  to  describe  the  arrangement  of  military 
troops  during  battle.  In  this  document,  it  is  defined  as  the  hierarchy  or  separation  of 
military  command  or  of  a  headquarters.  The  lower  the  echelon  number,  the  higher  the 
command  in  the  reporting  chain.  For  instance,  an  Echelon  II  command  is  one  level  above 
an  Echelon  III  in  the  reporting  chain  of  command 

Identity  -  Identities  are  pieces  of  information  that  identify  a  users  association  of 
existence. 

Identity  and  Access  Management  -  a  set  of  processes  and  technologies  to  more 
effectively  and  consistently  manage  user  objects  over  relatively  large  numbers  of  systems 
and  directories. 

Locked  -  Account  not  able  to  be  accessed  by  individual  but  e-mail  will  continue  to  be 
routed  to  the  mailbox. 

New  Account  -  Account  that  has  never  been  established  on  the  NMCI  Network.  Usually 
the  result  of:  Accession  or  New  Employee  (Civilian). 

Non-Chargeable  Account  -  NMCI  Account  that  has  been  deactivated  and  the  member 
does  not  have  access  to  NMCI. 

Pending  -  Account  Established  but  has  not  been  accessed  by  user. 

Provisioning  -  The  automation  of  business-oriented  work  flow  of  systems,  resources, 
services  and  devices  to  employees,  partners,  contractors,  suppliers  and  temporary 
workers. 

Reactivated  Accounts  -  A  Deactivated  Account  that  has  been  reestablished  with  stored 
digital  identity. 

Seat  Identification  -  a  unique  eight  (8)  digit  number  assigned  to  each  seat  entered  into  the 
NMCI  Enterprise  Tool  (NET)  database.  Every  asset  that  is  considered  a  seat  in  NET  is 
assigned  a  SeatID.  Any  peripherals  that  are  attached  to  a  seat  do  not  have  its  own 
SeatID.  If  a  peripheral  is  ordered  as  a  seat  (stand  alone)  then  it  would  have  its  own 
SeatID. 

Stale  -  System  indicates  a  locked  account  that  has  remained  inactive  for  over  30  days 
with  no  attempts  to  utilize  the  account. 
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I.  INTRODUCTION 


A.  PURPOSE 

This  thesis  analyzes  how  the  U.S.  Navy  Reserve  is  currently  managing  Navy 
Marine  Corps  Intranet  (NMCI)  accounts.  The  research  defines  seat  management, 
provides  a  brief  history  of  NMCI,  identifies  the  As-Is  process  for  account  management 
and  the  associated  significant  challenges,  provides  an  analysis  of  “best-of-breed” 
commercial-off-the-shelf  (COTS)  products  used  by  industry  for  account  management, 
and  outlines  best  practices  of  commercial  companies  that  have  adopted  the  seat 
management  concept.  It  also  explores  and  proposes  a  non-technical  enterprise  solution 
that  could  feasibly  be  implemented  by  Commander,  Navy  Reserve  Force  (CNRF)  to 
minimize  the  current  account  management  challenges. 

B.  BACKGROUND 

Government  agencies  have  been  implementing  seat  management  concepts  with 
information  technology  (IT)  contracting  since  1997.  Also  known  as  desktop  outsourcing, 
seat  management  is  the  process  where  organizations  outsource  the  maintenance  and 
ownership  of  their  desktop  personal  computers  (PCs),  including  all  required  hardware, 
software,  network  support,  and  help  desk  services  to  commercial  companies  that 
specialize  in  those  services.  Simply  stated,  seat  management  involves  buying  desktop 
computing  power  as  a  unified  service  with  pricing  computed  on  a  “per  user”  or  a  “per 
seat”  basis,  hence,  the  term  seat  management.  One  method  of  a  seat  management 
environment  allows  the  contractor  to  maintain  ownership  of  all  the  resources  such  as 
network  and  desktop  hardware  and  software,  and  delivers  the  resultant  computing 
capability  as  a  service,  often  compared  to  a  utility. 

The  NMCI  contract,  arguably  the  largest  and  most  complex  seat  management 
effort  attempted  to  date,  was  awarded  in  October  2000  as  a  multi-year  performance-based 
contract.  Awarded  as  an  indefinite  deliver/indefinite  quantity  (IDIQ)  contract  with 
Electronic  Data  Systems  (EDS)  Corporation  as  the  prime  contractor,  NMCI  is  expected 
eventually  to  provide  service  for  roughly  400,000  Navy  and  Marine  Corps  personnel. 
The  contract  is  valued  between  $9-$  13  billion  and  was  awarded  as  a  five-year  base 
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contract  covering  fiscal  years  2001  through  2005,  with  a  three-year  option  period 
continuing  into  fiscal  years  2006-2008. 

There  can  be  many  benefits  derived  from  seat  management  contracting  and  the 
development  of  the  NMCI  naturally  inherited  many  of  these  benefits.  With  proper 
structuring  of  the  requirements  and  the  contract,  commercial  expertise  and  best  practices 
can  be  leveraged  to  result  in  improvements  such  as  quality  improvement,  better  response 
time,  higher  reliability  and  availability,  and/or  reduced  system  downtime.  While 
organizations  that  embark  on  a  seat  management  approach  hope  to  save  money,  most 
realize  benefits  are  in  the  area  of  quality  improvement. 

Management  of  these  benefits  present  many  challenges  for  the  organizations  that 
have  chosen  to  embrace  seat  management.  The  structure  of  the  Department  of  the  Navy 
(DoN)  and  the  diversity  in  its  business  processes  caused  the  management  of  NMCI  to  be 
unique  and  more  complex  than  the  management  of  such  contracts  in  the  commercial 
sector.  The  large  number  of  transient  military  personnel  that  relocate  every  two  to  three 
years  for  new  military  assignments  and  the  numerous  geographically  dispersed  shore- 
based  commands  that  reside  on  the  Intranet  adds  to  the  complexity  of  information 
technology  (IT)  management  in  the  NMCI  environment.  One  of  the  many  challenges 
involves  the  management  of  all  associated  accounts  that  reside  on  NMCI  in  addition  to 
the  unused  accounts  affiliated  with  each  seat.  This  challenge  continues  to  haunt  the  U.S. 
Navy  Active  Component  (USN  AC)  and  the  U.S.  Navy  Reserve  Component  (USN  RC) 
resulting  in  an  estimated  additional  cost  of  $35  million  per  year. 

The  objective  of  this  thesis  is  to  analyze  the  current  processes  associated  with 
account  management.  Recommendations  are  provided  on  improvements  to  simplify  the 
management  of  accounts  and  decrease  the  $35  million  additional  annual  cost. 

C.  RESEARCH  QUESTIONS 

1.  Primary  Research  Question 

How  might  the  U.S.  Navy  Reserve  Component  (USN  RC)  effectively  manage 
accounts  in  the  NMCI  environment? 
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2.  Secondary  Research  Questions 

•  How  were  the  accounts  allocated  during  NMCI  deployment? 

•  How  are  the  USN  RC  Customer  Technical  Representatives  (CTRs) 
currently  tracking  NMCI  accounts  per  region? 

•  How  is  the  Navy  Reserve  Forces  Command  currently  managing  NMCI 
accounts  for  the  USN  RC? 

•  How  is  the  U.S.  Navy  Active  Component  (USN  AC)  currently  managing 
NMCI  accounts? 

•  How  are  some  of  the  large  commercial  companies,  which  have  adopted 
the  seat  management  concept,  successfully  managing  accounts  across  an 
enterprise  solution? 

•  What  are  the  ‘best-of-breed’  COTS  products  used  by  industry  for  account 
management? 

•  What  would  be  a  feasible  non- technical  solution  that  the  USN  RC,  and 
perhaps  the  USN  AC,  could  implement? 

D.  SCOPE  AND  LIMITATIONS 

The  scope  of  this  thesis  includes  an  in-depth  analysis  of  the  USN  RC’s  current 
process  and  the  sub-processes  involved  in  managing  NMCI  accounts.  This  analysis 
defines  and  outlines  the  As-Is  process  for  account  management.  The  scope  analyzes  how 
commercial  companies  that  have  implemented  the  seat  management  concept  are 
managing  their  remote  locations  and  the  feasibility  of  the  USN  RC  implementing  a 
similar  solution.  “Best-of-breed”  COTS  tools  used  by  industry  for  account  management 
were  reviewed  for  feasibility  of  use  as  a  management  tool  by  the  USN  RC.  The 
recommendations  include  a  non-technical  solution  for  minimizing  the  current  challenges 
affiliated  with  account  management.  The  analysis  is  from  a  business  process  perspective. 
Therefore,  a  software  solution  is  not  provided  as  a  deliverable  and  is  beyond  the  scope  of 
this  thesis. 

E.  METHODOLOGY 

The  methodology  used  to  fulfill  the  requirements  for  this  thesis  consisted  of  the 
following  steps.  First,  a  comprehensive  literature  review  of  journal  articles,  General 
Accounting  Office  (GAO)  reports,  and  other  library  information  resources  was  conducted 
to  understand  the  history  of  NMCI  and  its  progression.  Second,  an  in-depth  content 
analysis  was  conducted  of  official  websites,  presentations,  and  journals  to  understand  the 
pertinent  NMCI  contract  tenns  and  current  business  process.  Third,  phone  interviews,  a 
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review  of  presentation  material,  and  a  review  of  official  documents  were  utilized  to  grasp 
the  USN  RC  implementation,  cutover  plan,  and  key  challenges  with  NMCI.  Fourth,  a 
web-based  survey,  followed  by  phone  interviews,  was  primarily  used  to  gather  data  on 
the  manner  in  which  accounts  are  currently  managed  within  various  commands  across  a 
myriad  of  echelons.3  The  results  of  the  survey  were  used  to  determine  the  relationship 
between  each  of  the  sub-processes  and  their  correlation.  Fifth,  web  research  and  phone 
interviews  were  conducted  to  gather  data  from  commercial  companies  that  have 
implemented  the  seat  management  concept  successfully.  Sixth,  coordination  with 
vendors  and  web  research  was  the  method  used  to  analyze  “best-of-breed”  COTS 
packages  used  in  industry  for  account  management.  As  a  result  of  these  steps,  the 
researcher  was  able  to  evaluate  the  effectiveness  of  the  current  account  management 
process,  perform  a  feasibility  analysis,  and  make  recommendations  for  an  enterprise 
solution  to  account  management. 

F.  BENEFITS  OF  THE  RESEARCH 

This  thesis  analyzes  how  the  USN  RC  is  coping  with  the  current  account 
management  challenges  and  defines  the  current  state  (i.e.,  As-Is  model)  of  managing 
accounts.  Additionally,  it  provides  an  analysis  of  COTS  packages  that  could  consolidate 
several  applications  that  are  currently  used  for  account  management,  analyzes 
commercial  companies  that  have  implemented  the  seat  management  concept  and 
identifies  best  practices  used  to  make  seat  management  successful  in  their  environment. 
Recommendations  are  provided  on  how  the  USN  RC  can  better  manage  accounts  by 
making  modifications  to  the  current  information  technology  systems,  establishing  an 
enterprise  solution,  and  by  making  changes  in  the  business  processes.  Implementation  of 
these  recommendations  is  expected  to  yield  a  cost  savings  of  approximately  $35  million 
and  to  create  an  efficient  and  standardize  management  process.  This  study  could  not  only 
benefit  the  USN  RC,  but  also  the  USN  AC  as  they  are  also  faced  with  similar  NMCI 
challenges. 


3  An  Echelon  is  a  Civil  War  term  used  to  describe  the  arrangement  of  military  troops  during  battle.  In 
this  document,  it  is  defined  as  the  hierarchy  or  separation  of  military  commands  or  of  a  headquarters.  The 
lower  the  echelon  number,  the  higher  the  command  in  the  reporting  chain.  For  instance,  an  Echelon  II 
command  is  one  level  above  an  Echelon  III  in  the  reporting  chain  of  command 
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G.  ORGANIZATION  OF  THE  THESIS 

Chapter  II  provides  a  comprehensive  history  of  NMCI  and  the  road  to  transition 
completion  for  the  USN  RC.  Chapter  III  gives  a  detailed  analysis  of  the  challenges 
associated  with  managing  accounts.  Chapter  IV  defines  the  methods  used  to  determine 
the  current  state,  identifies  how  the  data  was  obtained  to  determine  the  current  state,  and 
provides  a  detailed  outline  of  the  current  sub-processes  associated  with  account 
management.  Chapter  V  provides  an  in-depth  analysis  of  “best-of-breed”  COTS  products 
as  well  as  an  analysis  of  industry  best  practices  for  outsourced  seat  management 
contracts.  Chapter  VI  provides  recommendations  for  an  enterprise  solution  for  managing 
accounts.  It  also  contains  research  conclusions  and  answers  to  the  research  questions. 


5 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


6 


II.  NMCI  HISTORY  AND  THE  ASSOCIATED  BENEFITS 


A.  INTRODUCTION 

This  chapter  discusses  the  history  of  the  NMCI  program  to  establish  the 
background  and  reference  point  for  the  analysis  of  the  associated  account  management 
challenges  presented  later  in  the  thesis.  It  also  provides  a  description  of  the  NMCI 
program  and  the  inherent  benefits  of  seat  management  contracting. 

B.  DRIVING  FACTORS  FOR  THE  NEED  TO  CHANGE 

Prior  to  the  inception  of  NMCI,  Department  of  the  Navy  (DoN)  was  faced  with 
many  challenges  and  shortfalls  in  IT  management,  acquisition,  and  operations.  The 
declining  manning  levels  and  budget  led  to  reductions  in  military  and  civilian  personnel. 
The  competition  created  by  industry  made  it  increasingly  difficult  to  retain  a  highly- 
skilled  IT  workforce.  The  rapid  growth  and  evolution  of  technology  outpaced  DoN’s 
ability  to  remain  current,  and  thus  resulting  in  obsolete  business  processes,  antiquated 
infrastructure,  and  legacy  computers  riding  on  low  speed  network  circuits.  Declining 
budgets  did  not  match  IT  requirements  for  hardware  and  software  refreshment,  which  led 
to  IT  assets  being  retained  longer  than  recommended  by  industry  standards  without 
maintenance  contracts  to  support  them.  Funding  was  given  to  the  larger  System 
Commands  (SYSCOMs)  and  the  Research  and  Development  (R&D)  labs  to  build  and 
design  technologically  advanced  networks  to  support  their  mission.  These  commands  are 
called  the  “haves”  while  the  smaller  commands  were  given  minimal  IT  funding  and  yet 
were  required  to  work  with  antiquated  systems  that  caused  them  to  expend  a  good  portion 
of  their  resources  to  managing  and  maintaining  the  systems.  These  commands  are 
frequently  considered  the  “have-nots”.  [Ref.  7] 

Joint  Vision  2010  mandated  that  future  operating  environments  strongly 
emphasize  the  decisive  advantage  conferred  by  superior  information  management  and 
knowledge  dominance  in  order  to  achieve  operational  success  and  information 
superiority.  Knowledge  dominance  is  defined  as  the  ability  to  establish  a  force  that  can 
leverage  technology  to  access  knowledge  and  quickly  share  information  in  the  form  of 
education,  learning,  training,  and  human  expertise  using  a  networked  joint  architecture. 
Infonnation  superiority  can  be  defined  as  providing  military  forces  with  the  capability  to 
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collect,  process,  and  disseminate  an  uninterrupted  flow  of  infonnation  while  exploiting  or 
denying  an  adversary’s  ability  to  do  the  same.  In  a  non-combat  situation  this  means  that 
U.S.  forces  would  have  the  necessary  information  to  achieve  their  operational  objectives. 
In  order  to  provide  the  operational  environment  necessary  to  promote  infonnation 
superiority,  connectivity  is  necessary  between  all  parts  of  shore  establishments,  and  with 
all  deployed  forces  at  sea  and  ashore.  This  connectivity  would  enable  an  environment  in 
which  all  members  can  collaborate  freely,  share  information,  and  organizational  learning 
can  be  fostered.  [Ref.  6]. 

The  DoN  reshaped  its  vision  to  support  the  speed,  volume,  and  diversity  of 
knowledge  required  to  operate  effectively  within  the  framework  of  joint  military  forces. 
DoN  is  building  the  infrastructure  necessary  to  achieve  information  superiority  and 
support  knowledge  dominance.  Ashore,  the  infrastructure  takes  the  form  of  the  Navy 
Marine  Corps  Intranet  (NMCI)  that  will  ultimately  connect  all  DoN  ashore  facilities  and 
pennit  rapid,  secure,  infonnation  transfer,  and  universal  Internet  access. 

C.  NAVY  MARINE  CORPS  INTRANET  (NMCI) 

NMCI  is  a  corporate-style  Intranet  that  links  Navy  and  Marine  Corps  shore-based 
installations.  The  NMCI  contract  was  awarded  in  October  2000  as  one  of  the  DoN’s 
responses  to  the  requirement  of  Joint  Vision  2010  to  obtain  information  superiority  [Ref. 
1].  The  contract  was  designed  using  the  principles  of  seat  management  in  order  to  reap 
the  benefits  inherent  in  seat  management  concepts.  It  is  a  multi-year  performance-based, 
indefinite  deliver/indefinite  quantity  (IDIQ)  contract  with  a  dollar  value  ranging  $9-$  1 3 
billion  with  Electronic  Data  Systems  (EDS)  Corporation  as  the  prime  contractor  and 
includes  a  five-year  base  period  covering  fiscal  years  2001  through  2005  with  a  three- 
year  option  period.  Once  Full  Operational  Capability  (FOC)  is  reached,  the  Intranet  is 
expected  to  provide  network  services  for  roughly  400,000  U.S.  Navy  and  Marine  Corps 
shore-based  computer  workstations,  also  called  “seats.” 

The  concept  behind  the  NMCI  transformation  effort  is  to  apply  the  speed  and 

opportunities  of  Internet  technology  not  only  to  warfighting  tasks,  but  also  to  the  daily 

activities  of  personnel,  and  especially  those  dealing  with  administrative  and  support 

tasks.  The  purpose  of  NMCI  is  to  provide  the  Navy  and  Marine  Corps  with  secure 

universal  access  to  integrated  voice,  video  and  data  communications  (ViViD)  as  well  as 
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to  eliminate  interoperability  problems  across  stove-piped  networks  and  to  remove 
anomalies  in  the  network  thereby  improving  productivity  and  speed  of  command.  It  also 
includes  classified  and  unclassified  connectivity  in  its  architecture  to  make  it  arguably 
one  of  the  most  robust,  comprehensive,  enterprise-wide  outsourced  seat  management 
contracts  to  date.  One  of  the  primary  goals  identified  in  the  NMCI  contract  is  to  bring  the 
Navy  and  Marine  Corps’  disparate  information  technology  ashore  systems  together  under 
a  single  vendor  to  increase  security  and  interoperability.  The  ultimate  goal  is  to  allow 
DoN  operators  to  focus  on  their  mission  rather  than  be  concerned  with  IT  services  and  all 
the  technical  problems  related  with  infrastructures  and  administration  activities. 

D.  EXPECTED  BENEFITS  OF  NMCI 

With  the  implementation  of  NMCI,  DoN  was  able  to  take  advantage  quickly  of 
the  several  benefits  that  are  potentially  inherent  in  a  seat  management  contract.  Once 
fully  implemented,  the  NMCI  contract  will  consolidate  Navy  and  Marine  Corps  networks 
that  are  scattered  over  300  military  bases  into  a  single  enterprise-wide  managed  service. 
The  benefits  received  from  this  enterprise  approach  include  improved  interoperability  and 
access  as  the  consolidation  of  networks  and  locations  will  eliminate  locally  built  stove- 
piped  systems.  Consolidating  the  IT  budget  at  the  U.S.  Navy  Active  Component  (USN 
AC)  and  the  U.S.  Navy  Reserve  Component  (USN  RC)  Echelon  II  levels  enabled 
increased  visibility  of  IT  costs.  Enterprise-wide  quality  improvements  have  also  been 
realized  in  the  form  of  better  response  time,  more  reliable  system  availability,  and 
reduced  downtime. 

Another  benefit  of  NMCI  is  improved  security.  Consolidating  the  stove-piped 
networks  to  form  an  enterprise-wide  solution  has  exponentially  increased  security 
throughout  DoN.  When  consolidating  networks,  multiple  access  points  are  eliminated 
reducing  points  of  vulnerability  in  the  system.  [Ref.  5].  NMCI  provides  stringent 
information  assurance  support  and  increases  the  level  of  security  management  to 
unprecedented  heights  across  DoN. 

“Technology  refreshment”  is  another  advantage  of  seat  management  contracting. 
Technology  refreshment  has  been  defined  as  the  periodic  replacement  of  commercial-off- 
the-shelf  (COTS)  components  such  as  processors,  displays,  operating  systems,  and 

software,  to  support  the  continued  operation  of  the  system  through  an  indefinite  service 
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life.  Technology  refreshment  is  a  way  to  extend  the  useful  life  of  IT  resources  while 
keeping  abreast  of  technological  advances.  Such  planned  upgrades  not  only  ensure  that 
systems  stay  current  with  the  latest  commercial  technology,  they  also  allow  the 
organization  to  stay  ahead  of  the  “obsolescence  curve.”  [Ref.  8] 

Information  technological  advances  have  been  coming  so  quickly  and  thus 
resulting  in  a  huge  burden  for  an  organization  to  plan  and  budget  for  upgrades  in  the 
traditional  fashion.  By  incorporating  a  technology  refreshment  requirement  into  the 
NMCI  seat  management  contract,  EDS  becomes  responsible  for  planning  and 
implementing  the  upgrades  at  no  additional  costs  beyond  the  already  known  seat  pricing. 
The  NMCI  contract,  for  example,  contains  technology  refreshment  requirements  that 
software  be  updated  annually  or  to  maintain  one  revision  from  the  current  state,  while 
hardware  is  updated  every  three  years.  [Ref.  9].  Military  organizations  like  the  Navy 
Reserve  would  have  not  been  able  to  maintain  such  technology  refreshment  requirements 
without  the  implementation  of  NMCI. 

Another  benefit  of  NMCI  is  that  it  allows  DoN  to  divert  personnel  resources 
previously  performing  routine  tasks  associated  with  desktop  IT  resources  (e.g.,  helpdesk 
personnel).  By  transferring  the  ownership  and  responsibility  for  the  resources  to 
commercial  vendors  who  specialize  in  IT  support,  DoN  personnel  can  focus  on  the 
command’s  core  mission  rather  than  running  desktop  systems.  This  benefit  of  NMCI  is 
even  more  important  today  since  the  Government  is  finding  it  more  difficult  to  compete 
with  the  private  sector  for  IT  personnel.  By  freeing  agency  personnel  from  the  day-to-day 
routine  support  tasks,  they  can  perform  other,  potentially  more  interesting  work  and  more 
business  sensitive  tasks.  Meaningful  work  may  help  to  retain  critical  IT  professionals. 

With  NMCI,  DoN  obtains  secure  seamless  end-to-end,  integrated  service  delivery 
of  desktop  systems,  including  hardware  and  software  upgrades,  technical  support  and 
training.  They  will  simply  pay  a  fixed  monthly  fee  for  those  services  based  on  a  per-seat 
calculation.  Outsourcing  seat  management  effectively  shifts  responsibility  for  keeping 
pace  with  technological  changes  to  the  contractor,  “who  must  be  knowledgeable, 
adaptable  and  capable  of  constantly  assessing  how  to  deliver  better,  more  cost-effective 
desktop  services  to  the  end  user.”  [Ref.  4] 
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E.  CHAPTER  SUMMARY 

This  chapter  provided  an  overview  of  the  inception  of  NMCI  and  its  connection  to 
Joint  Vision  2010.  In  addition,  the  chapter  also  provided  a  historical  view  of  the 
multitude  of  services  provided  by  NMCI.  Many  are  inherent  in  seat  management 
contracting  and  some  are  unique  to  the  NMCI  contract.  The  chapter  concluded  with  an 
examination  of  the  benefits  of  NMCI  and  the  harvesting  opportunities  realized  by  DoN. 
The  next  chapter  provides  a  detailed  examination  of  the  account  management  challenges 
and  concerns  of  the  USN  RC. 
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III.  THE  ACCOUNT  MANAGEMENT  CHALLENGE 


A.  INTRODUCTION 

The  development  of  the  Navy  Marine  Corps  Intranet  (NMCI)  provides  an 
enterprise-wide  solution  to  seat  management  that  connects  all  Navy  and  Marine  Corps 
commands  on  one  network  platform.  The  Navy  Reserve  senior  leadership  realized  the 
benefits  of  such  a  network  and  fully  embraced  the  concept  as  they  encouraged  a  rapid 
implementation  of  NMCI  by  their  subordinate  commands. 

The  U.S.  Navy  Reserve  Component  (USN  RC)  was  considered  to  be  one  of  the 
“have-nots”  as  they  were  operating  old  hardware  (in  some  cases  with  Pentium  II  and 
Pentium  III  computers),  outdated  software  applications  (some  were  running  Microsoft 
Windows  98  operating  system),  and  antiquated  peripherals  to  support  the  Full  Time 
Support  (FTS)  and  the  Drilling  Reservists  (DRILLRES)  personnel  assigned  to  their  Navy 
Reserve  Activity  (NRA).  They  were  required  to  operate  with  a  reduced  IT  budget  and 
were  not  able  to  keep  abreast  of  the  pace  of  technology.  The  USN  RC  leadership  realized 
that  the  establishment  of  the  NMCI  would  provide  them  with  modern  technology  across 
all  NRAs  and  would  standardize  equipment  and  services  across  DoN. 

While  learning  from  some  of  the  early  lessons  of  their  U.S.  Navy  Active 
Component  (USN  AC)  counterparts  during  their  NMCI  cutover  and  planning,  the 
information  technology  leadership  of  the  USN  RC  began  to  develop  plans,  common 
profiles,  and  demand  models  that  would  assist  in  their  NMCI  transition.  Reserve 
commands  were  cutting  over  to  NMCI  and  ordering  accounts  at  a  rapid  pace.  They  soon 
realized  that  account  management  would  become  a  problem  as  DRILLRES  and  FTS 
began  to  transfer  to  other  NRAs,  be  recalled  to  active  duty,  and  retire  or  resign  while  their 
accounts  remained  active  at  the  losing  command.  The  transient  personnel  began  to 
relocate  faster  than  the  Navy  Reserve  senior  leadership  could  detennine  the  process  and 
set  policy  for  handling  the  accounts.  As  the  race  to  the  NMCI  cutover  began,  so  did  the 
challenge  of  account  management.  The  Navy  Reserve  senior  leadership  realized  that 
they  were  in  need  of  an  enterprise  solution  to  account  management  as  an  estimated  cost 
savings  of  approximately  $35  million  could  be  achieved. 
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Although  NMCI  is  very  beneficial,  many  challenges  remain  in  managing  such  a 
large-scale  contract.  The  focus  of  this  chapter  addresses  the  problems  incurred  by  the 
USN  RC  with  managing  over  80,000  accounts  for  DRILLRES,  Reserve  FTS,  and  civilian 
personnel  in  the  NMCI  environment.  Although  the  focus  is  on  the  USN  RC,  this  problem 
is  not  unique  to  them  but  is  also  experienced  by  the  USN  AC  as  well. 

B.  THE  CHALLENGE  IN  ORGANIZATIONAL  STRUCTURE 

When  the  NMCI  contract  was  awarded,  DoN  still  had  many  areas  that  required 
clearly  defined  processes  and  management  standards.  Account  Management  is  one  of  the 
areas  that  lacked  a  standard  enterprise-level  process,  which  led  to  the  problems  that  are 
experienced  today.  The  initial  intent  was  to  manage  the  accounts  at  the  Echelon  II  level 
and  it  was  at  this  level  that  “the  enterprise”  would  be  defined.  Management,  to  include 
acquisition  and  budget,  at  the  Echelon  II  level  meant  that  DoN  would  be  responsible  for 
the  overall  management  of  accounts  and  would  have  access  to  the  NMCI  operating  and 
funding  requirements  of  both  the  USN  AC  and  the  USN  RC.  All  accounts  were  to  be 
aggregated  and  distributed  at  the  enterprise  level.  [Ref.  10] 

The  definition  of  “the  enterprise”  did  not  evolve  as  initially  intended  with  the 
final  award  of  the  contract.  The  decision  was  that  overall  management  would  occur  at 
the  Echelon  II  claimant4  levels  of  the  USN  AC  and  the  USN  RC  instead  of  combining 
them  under  the  USN  AC  as  an  effort  to  simplify  the  management.  These  Echelon  II 
commands  would  then  be  responsible  for  all  NMCI  management  under  their  claimancy, 
which  further  required  that  all  budgeting  and  fiscal  responsibility  for  NMCI  also  be  given 
to  each  based  on  their  individual  requirements.  Thus  began  the  account  management 
challenges  of  today. 

When  the  NMCI  contract  was  awarded,  the  DoN  and  the  contractor  agreed  to 
couple  the  “seats”  with  user  accounts.  The  anticipated  seat  purchase  was  expected  to  be 
roughly  400,000  and  it  was  believed  that  adding  user  accounts  to  the  seat  for  one  cost 
would  not  only  provide  the  computers,  also  called  the  “seat”,  but  would  also  allow 
additional  user  accounts  to  be  assigned  to  the  hardware  at  no  additional  charge.  It  was 

4  A  claimant  denotes  the  next  level  of  management  below  the  Chief  of  Naval  Operations  headquarters 
staff  within  the  budget  arena.  In  the  Navy’s  tradition  of  relatively  decentralized  management,  the  major 
claimants  are  the  focal  point  for  executing  the  Strategic  Sourcing  Program. 
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decided  to  arrange  the  contract  so  that  each  unclassified  “seat”  would  be  accompanied 
with  two  “free  user  accounts”  and  that  each  classified  “seat”  would  lend  five  accounts 
“per  seat”.  This  approach  was  to  eliminate  the  need  for  DoN  to  purchase  a  large  quantity 
of  additional  user  account  services  from  the  contract  as  the  two  “free  user  accounts”  that 
would  accompany  the  400,000  unclassified  seats  would  be  sufficient  to  cover  the  DoN 
for  a  total  of  800,000  accessible  accounts. 

The  initial  goal  was  to  have  an  aggregated  “pool”  of  all  the  unused  user  accounts 
remaining  from  the  800,000  that  would  be  accessible  by  all  of  DoN.  When  needed, 
accounts  would  be  allocated  from  the  pool  and  deposited  back  to  the  pool  when  an 
account  is  no  longer  in  use.  The  800,000  free  user  accounts  were  expected  to  cover  the 
majority  of  the  users  requiring  access  to  NMCI  and  DoN  would  pay  a  minimal  service 
cost  for  any  additional  accounts  that  exceeded  this  amount. 

Separating  the  two  Echelon  II  claimants  when  defining  “the  enterprise”  (USN  and 
USN  RC)  dampened  this  plan  as  each  of  the  claimants  could  now  only  have  access  to  the 
seats  that  were  included  in  their  NMCI  service  order,  and  subsequently,  the  accounts  that 
accompanied  each  of  those  seats.  No  business  rules  were  developed  to  allow  accounts  to 
be  shared  between  the  claimants  to  achieve  the  intended  costs  savings  for  DoN.  This 
structure  created  problems  for  the  Navy  Reserve  because  they  would  require  a  plethora  of 
additional  user  accounts  above  the  total  derived  from  their  seats. 

The  USN  RC  structure  and  requirements  are  unique  when  compared  to  its  USN 
counterpart.  With  most  of  its  80,000  plus  force  in  DRILLRES  status,  there  was  not  a 
requirement  to  have  a  large  number  of  seats  but  a  need  existed  to  have  a  large  number  of 
accounts.  The  aforementioned  definition  of  the  enterprise  caused  them  to  order  a  large 
number  of  additional  user  accounts  from  the  NMCI  service  contract  as  the  total  free 
accounts  that  were  derived  from  the  seat  order  were  not  sufficient.  In  fiscal  year  2004,  it 
was  estimated  that  USN  had  approximately  a  surplus  of  70,000  unused  accounts  while 
the  USN  RC  was  required  to  purchase  support  services  for  approximately  30,000 
accounts  at  a  cost  of  approximately  $700  for  each  account  per  annum.  The  lack  of 
visibility  and  accessibility  across  claimants  led  the  USN  RC  to  spend  approximately  $30 
million  dollars  for  additional  user  accounts. 
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C.  COMMAND  MANAGEMENT 

The  NMCI  contract  is  a  service  contract  that  allows  its  customers  to  decide  what 
services  they  want  and  order  those  services  from  the  contractor.  The  services  are 
identified  as  Contract  Line  Items  (CLINs)  and  are  ordered  by  the  government’s 
representative  called  a  Customer  Technical  Representative  (CTR).  Appendix  A  includes 
a  list  of  the  CLINs.  The  CTRs  are  located  at  the  Echelon  II  level  and  possess  overall 
contract  management  responsibility  on  behalf  of  the  government.  The  CTR  also  has 
lower  level  representatives,  called  the  Deputy  Customer  Technical  Representative 
(DCTR)  and  Assistance  Customer  Technical  Representative  (ACTR),  who  are 
responsible  for  daily  NMCI  management  at  their  local  NRA.  The  business  rules  have 
established  a  distinct  difference  in  responsibility  between  them  as  the  ACTR  (also  called 
an  authorized  initiator),  who  is  responsible  for  sending  any  request  that  requires 
contractor  action  and  funding  approval  to  the  DCTR  (also  called  an  authorized 
submitter).  In  addition  to  managing  the  local  accounts,  the  DCTR  is  responsible  for 
reviewing  and  submitting  any  requests  generated  by  the  ACTR  and  has  been  granted 
authority  by  the  CTR  to  authorize  any  funding  requirement  to  support  submitted  requests. 
For  the  purpose  of  this  thesis,  the  tenns  technical  representative  and  account  manager  is 
used  synonymously. 

Although  the  CLINs  and  their  description  appear  in  Appendix  A,  one  of  the 
problems  with  account  management  involves  the  management  of  CLIN  0024  (Additional 
Non-Classified  Account)  and  CLIN  0026AL  (Administrative  Move  Add  Change).  Per 
the  contract,  CLIN  0024  is  defined  as  “an  additional  Non-Classified  Account  that 
provides  a  user  account  in  addition  to  those  provided  with  ordered  data  seat(s).”  The 
price  for  a  CLIN  0024  is  $58.26  per  month  or  approximately  $700  per  annum  [Ref.  1 1]. 
It  is  important  to  note  that  the  problems  identified  in  the  previous  section  of  a  high 
account-to-seat  ratio  have  resulted  in  the  USN  RC  paying  for  over  30,000  CLIN  0024’s. 
A  CLIN  0026AL  is  defined  as  an  administrative  Move,  Add,  Change  (called  a  MAC). 
Most  CLIN  0026 AL’s  are  a  one-time  chargeable  transaction  for  a  service  provided  by  the 
contractor  for  modifications  to  current  hardware/software  configurations  and  accounts. 
The  area  of  concern  for  this  thesis  is  charges  accrued  because  of  account-generated 
MAC’S.  The  price  for  each  CLIN  0026AL  request  is  $36.60. 
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Management  of  accounts  by  the  technical  representatives  has  also  been  a 
challenge.  The  lack  of  policy  and  standards  and  a  single  integrated  IT  solution  has 
caused  the  technical  representatives  to  spend  an  enormous  amount  of  time  reconciling 
what  seats  and  user  accounts  the  IT  management  systems  say  they  have  and  what  is 
actually  on-site. 

Business  processes  are  not  in  place  to  direct  the  proper  management  of  a  user 
account  from  its  inception  to  the  termination  of  service  (cradle  to  grave).  The  following 
sections  provide  more  detail  on  the  types  of  issues  that  the  USN  RC  is  currently 
experiencing  with  account  management. 

1.  Duplicate  Accounts 

Problems  exist  with  technical  representatives  establishing  new  accounts  for  users 
that  already  have  an  NMCI  account  in  Active  Directory  whereby  creating  what  is  called  a 
duplicate  (or  excess)  account,  which  increases  the  user  account  total  and  the  requirement 
for  CLIN  0024’s.  For  those  managers  that  are  investigating  whether  an  account  already 
exists  before  submitting  a  request  for  a  new  account,  they  are  not  properly  trained  on 
which  databases  or  systems  should  be  used  to  verify  a  user’s  status.  Many  check  the 
Global  Address  Lists  (GAL)  for  verification,  but  should  also  verily  account  status  in  the 
Active  Directory.  The  GAL  and  Active  Directory  differ  in  that  the  GAL  provides  a  list 
of  email  addresses  while  the  user  account  is  actually  generated  in  Active  Directory.  A 
user  may  not  necessarily  have  an  email  address  listed  in  the  GAL,  but  may  have  a 
chargeable  account  listed  in  Active  Directory.  Conversely,  the  GAL  may  contain 
multiple  email  accounts  for  users  that  are  not  listed  in  Active  Directory.  In  order  for  a 
manager  to  accurately  detennine  all  the  duplicate  accounts,  communication  would  be 
required  with  an  NMCI  system  administrator  to  gain  access  to  both  the  hidden  and  visible 
accounts  in  Active  Directory.  Many  scenarios  exist  in  which  a  duplicate  account  can  be 
created.  In  order  for  the  reader  to  understand  the  challenge,  the  next  two  paragraphs 
provide  two  examples  of  the  types  of  scenarios  that  could  result  in  the  creation  of  a 
duplicate  account. 

A  duplicate  account  can  be  difficult  to  determine  when  a  user  has  a  common 

name  (i.e.,  John  Smith).  An  example  is  a  current  NMCI  user  with  a  common  name  who 

reports  to  a  gaining  command.  The  technical  representative  asks  if  a  NMCI  user  account 
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already  exists  and  John  Smith,  having  never  used  his  NMCI  account  before,  says  that  one 
does  not  exist.  The  technical  representative  checks  the  GAL  or  Active  Directory,  notices 
a  large  number  of  John  Smith’s  in  the  system,  and  therefore,  elects  to  create  a  new 
account  for  the  user.  The  user  now  has  an  account  created  from  a  previous  command  and 
a  newly-created  user  account  from  his  new  command.  For  the  Navy  Reserve,  this  would 
equate  to  payment  of  two  CLIN  0024s  if  the  two  “free”  accounts  that  accompanied  the 
seats  are  completely  occupied. 


Example  1 :  Creation  of  Duplicate  account 


Figure  1.  Duplicate  Account  Creation  Example  1. 


Duplicate  accounts  are  also  difficult  to  detennine  when  an  inadvertent  creation  is 
made  when  a  user  is  transferring  to  a  new  location  while  his  losing  command  is  preparing 
for  NMCI  transition.  For  example,  a  user  (i.e.,  John  Doe)  was  previously  located  at  a 
command  (for  instance,  San  Diego)  that  was  in  the  beginning  phases  of  transition  (called 
cutover)  to  NMCI.  The  local  ACTR  submitted  an  account  creation  request  for  John  Doe 
when  the  command’s  initial  NMCI  order  was  submitted.  In  the  middle  of  the  San  Diego 
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transition,  John  Doe  relocates  to  another  command  (for  instance,  Washington  D.C.)  and 
he  was  unaware  that  the  San  Diego  NRA  initiated  a  pending  service  request  to  create  a 
new  account.  The  Washington  D.C.  command,  having  already  cutover  to  NMCI,  submits 
a  request  to  have  a  new  account  created  for  John  Doe  and  the  newly  created  account 
name  is  John  Doe  2.  The  submission  of  the  request  for  a  new  service  results  in  the 
claimant  paying  for  a  duplicate  account  for  John  Doe. 


Example  2:  Creation  of  Duplicate  account 


Transferring  Command 
(San  Diego) 


ACTREchV 


Usef 


Figure  2.  Duplicate  Account  Creation  Example  2. 


Possibly  the  worse  case  scenario  for  creating  a  duplicate  account  is  when  a  local 
account  manager  intentionally  does  not  verify  if  an  account  exists  in  any  of  the  available 
database  resources  when  a  user  reports  to  the  command.  In  some  cases,  negligent 
management  oversight  has  been  the  cause  of  duplicate  account  creation. 
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Although  not  all-inclusive,  the  aforementioned  examples  provide  insight  into  the 
possibility  of  an  account  manager  creating  duplicate  accounts  in  a  highly  complex 
management  process. 

2.  Multiple  Accounts 

The  unique  nature  of  the  Navy  Reserve  requires  some  personnel  maintain  a 
duplicate  account  with  valid  reason.  A  duplicate  account  that  has  been  justified  by  the 
claimant  is  called  a  multiple  account.  Multiple  accounts  are  valid  accounts  that  are  given 
based  on  a  job  or  “role”  that  the  account  holder  may  perfonn  in  an  organization.  A 
DRILLRES  may  have  a  Reserve  account  funded  by  the  USN  RC  claimant,  and  another 
separate  NMCI  account  for  a  civilian  occupation  funded  by  the  claimant  over  that 
organization.  The  “role”,  or  job  function,  of  an  NMCI  user  detennines  the  need  for 
multiple  accounts. 

For  example,  a  DRILLRES  will  have  a  Reserve  account.  Depending  on  the  job 
functions  and  the  level  of  access  required,  it  is  possible  that  a  civilian  occupation  requires 
NMCI  access,  and  thus,  a  separate  unclassified  account  may  be  required.  As  a 
DRILLRES,  special  access  might  be  required  to  a  classified  network,  which  will  require 
a  third  NMCI  account.  The  separate  account  would  be  required  for  the  classified  network 
because  the  unclassified  and  classified  NMCI  networks  are  physically  separated  for 
security  reasons.  Since  they  are  physically  separated,  there  is  a  different  Active 
Directory  and  different  servers  that  support  the  network,  and  therefore,  require  a  different 
account.  An  NMCI  user  could  have  many  accounts  depending  on  the  “roles”  that  must 
be  performed.  The  “role”  is  what  drives  the  account  creation,  and  thus,  increases  the  cost 
for  managing  each  of  those  additional  accounts  when  purchasing  a  CLIN  0024. 

3.  Inactive  or  Unused  Accounts 

Currently,  the  USN  RC  is  paying  for  personnel  accounts  that  have  transferred  to 
active  duty,  separated  or  retired  from  the  Navy  Reserve,  transferred  to  a  non-NMCI 
command,  and  even  deceased  personnel.  Accounts  for  users  that  fall  in  one  of  these 
categories  have  shown  no  activity  and  are  categorized  as  an  inactive  or  an  unused 
account.  However,  funding  is  still  allocated  to  cover  the  cost  of  these  accounts. 
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Figure  3  outlines  the  six  categories  of  accounts.  [Ref.  12]  Of  these  categories, 
chargeable  unused  accounts  are  categorized  as  active,  locked,  stale,  or  disabled.  An 
“active”  account  is  a  chargeable  account  actively  used  by  an  NMCI  account  holder.  An 
account  that  is  “locked”  is  a  chargeable  account  that  is  not  accessible  by  a  NMCI  account 
holder.  A  “stale”  account  is  a  NMCI  system  term  used  to  identify  an  account  that  has 
remained  inactive  for  over  30  days  with  no  attempts  to  utilize  the  account.  A  “disabled” 
account  is  a  chargeable  account  status  not  accessible  and  all  email  is  rejected.  An  account 
is  placed  in  this  status  when  a  user  has  not  attempted  to  access  NMCI.  All  of  these  cases 
produce  unnecessary  additional  costs  for  the  USN  RC  and  the  DoN. 
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Figure  3.  Draft  NMCI  Instruction. 


A  report  produced  by  EDS  in  December  2004  revealed  that  there  were 
approximately  18,600  accounts  that  fell  into  one  of  these  categories.  [Ref.  10]  Action 
should  be  taken  to  move  these  accounts  to  one  of  the  non-chargeable  categories  of 
deactivation  or  deletion,  but  there  is  resistance  in  arbitrarily  doing  so  without  approval 
from  the  Echelon  II  claimant.  The  Navy  Reserve  continues  to  pay  for  these  accounts 
even  with  substantial  evidence  of  no  activity. 

4.  Excessive  Move,  Add,  Change  Request 

Transferring  user  accounts  to  other  NMCI  commands  requires  the  technical 
representative  to  submit  a  chargeable  MAC  request,  or  CLIN  0026,  to  the  DCTR.  Close 
coordination  is  required  by  both  the  transferring  command  and  the  gaining  command  to 
alleviate  multiple  MAC  submissions  for  the  same  account.  For  example,  the  technical 
representative  is  notified  that  an  NMCI  user  will  be  transferring  from  the  local  command. 
The  transferring  technical  representative  submits  a  MAC  to  have  an  account  deactivated 
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while  a  member  is  in  travel  status.  This  is  one  chargeable  transaction.  When  the  member 
reports,  the  gaining  command  submits  a  MAC  to  have  the  member’s  account  transferred 
to  their  activity  and  could  possibly  generate  a  third  MAC  to  have  the  account  reactivated. 
This  creates  another  chargeable  transaction.  Proper  coordination  between  the  losing  and 
gaining  command  could  have  eliminated  the  need  for  multiple  MACs  and  required  the 
payment  for  one  CLIN  0026. 

5.  Multiple  Stove-Piped  IT  Systems 

Since  a  single-integrated  NMCI  IT  management  tool  does  not  exist,  technical 
representatives  are  required  to  use  multiple  IT  systems  to  perfonn  overall  account  and 
seat  management.  Data  residing  in  a  myriad  of  systems  generates  problems  with  data 
synchronization  and  accuracy.  The  NMCI  Enterprise  Tool  (called  NET)  is  a  web-based 
portal  used  as  a  data  repository  for  recording  information  about  all  seats  and  peripherals 
at  each  site.  Simply  stated,  it  is  DoN’s  inventory  management  system  and  also  is  the 
gateway  used  to  order  services  to  be  delivered  on  NMCI.  Initially,  it  was  built  to 
maintain  a  record  of  hardware  and  software.  A  later  version  enabled  some  account 
information,  in  the  form  of  profiles,  to  be  added  by  the  users,  but  the  database  is  not  an 
accurate  reflection  of  the  accounts  existing  in  each  command  and  is  not  robust  enough  to 
include  all  the  information  required  to  manage  accounts  properly.  In  its  current 
configuration,  NET  does  not  effectively  perfonn  the  account  management  function. 
Additionally,  technical  representatives  must  use  the  Global  Address  List  (GAL)  or  Active 
Directory  to  verify  the  status  of  a  new  or  existing  account  of  gaining  or  transferring 
personnel  since  the  account  data  is  currently  inaccurate  in  NET. 
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Enterprise  Tool 


Welcome, 

Gi.ives, Gwendolyn 


|  Change  My  Password  |  Log  Off  | 


Welcome  Graves, Gwendolyn 

Action  Items  (Inbox) 
W 

Messages 


Latest  News 


Last  Updated:  December  6th.  2004 
NET  CLIN  Updates 


Latest  NET  News 

If  you  have  any  questions  or 
experience  a  problem  with  NET, 
please  contact  the  NET  National  Help 
Desk  at  (301)866-1 41 7  or 
NET.HelpDeski.34mco.com 


Figure  4.  NMCI  Enterprise  Took  Web  Portal. 


Technical  representatives  are  required  to  use  a  separate  tool  to  validate  NMCI  seat 
and  account  orders.  Electronic  Marketplace  (called  eMarketplace)  is  the  web-based  tool 
used  to  perform  monthly  validations  on  billing  invoices.  The  validation  is  a  method  of 
verifying  that  the  contractor  is  billing  for  existent  services  at  their  location.  Some 
interface  between  NET  and  eMarketplace  exists  but  the  two  systems  are  not  properly 
synchronized,  and  therefore,  the  data  does  not  match. 
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Address  https :  //www,  ecommerce.nmd-eds.com/ordering/ordering menu.jhtml 


eMarketplace 

Wliat'sNew?  Help 

NMCI 

haw  mai ini  conns  iNHANtr  | 

Home 

Services 

Welcome  to  the  NMCI  eMarketplace  ordering  main  menu  page. 

From  here  you  can  create  a  new  order  request,  view  an  existing  request  or  T ask  Order  that  you 
created,  or  submit  a  request  for  quote  on  an  upriced  CLIN.  To  begin  any  of  the  tasks  listed 
below,  simply  click  on  the  name  of  the  task. 

Ordering 

Reporting 

►  Create  New  Order  Reouest 

►  View  Fxistinn  Task  Order  nr  Order  Rem  jest 

►  Rem  jest  Quote  fnr  Unoriced  Services 

Preferences 

V  Perform  Task  Order  Modification 

Log  Off 

►  Create  New  Order  Reauest  Based  UDon  an  Existina  Order 

Customer  Service 

Figure  5.  eMarketplace  Website. 


MACs  are  submitted  and  managed  using  a  separate  web-portal  called  the  Service 
Request  Electronic  Form  (SR  eForm).  The  SR  eForm  is  the  contactor’s  tool  for 
managing  MAC  requests.  The  technical  representative  must  enter  any  request  for  a  MAC 
into  the  SR  eForm  and  the  request  is  eventually  routed  to  the  contractor  electronically. 


|  hKpJ/nww.nmcHsf.ccm/srf  jwmflndfrx.Mp 


SERVICE  REQUEST  EFORM 


m3 


Welcome  to  tho  now  SRoF.  All  users  are  now  required  to  reqtster  in  otdor  to  use  tho  s 

SRel  version  1  i.uwcrt  usirueboni «  Hcmm  Motes 


Submittal  of  Bulk  Request  forms  have  been  suspended  until  foither  notice 
MIucIkk  Oclnbirt  9,  .1114  Ihn  prucmrsmq  ol  bulk  mquivjts  uim  no  Innqirr  accitpli'il 


All  requests  must  be  submitted  one  request  per  submission  (one  to  one  basis) 
unit  may  cinty  tm  submitlmt  on  iqrptmvil  NMCI  farms  nvatluhlii  an  tlus  wih  p;iqi- 


I  oqin  ID  | 
Password  | 


Reset  |  Login  | 


Forgot  Password?  New  User? 
Mae*  Confirmation  Code? 


ijwss; 


Figure  6.  Service  Request  Electronic  Form  Web  Portal. 
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Since  most  of  these  management  systems  do  not  interface  with  each  other  and  are 
not  fully  integrated,  the  data  contained  in  them  are  not  synchronized  across  the  enterprise 
and  a  true  corporate  data  repository  does  not  exist.  The  lack  of  a  fully  integrated  system 
requires  the  technical  representatives  to  pull  data,  in  some  cases  redundant  data,  from 
each  to  perform  daily  routine  tasks.  Currently,  the  array  of  systems  has  created  an 
intense  manual  process,  and  in  their  current  configuration,  these  systems  do  not 
effectively  support  account  management.  The  various  IT  stove-piped  systems  have 
caused  inefficiencies  in  the  overall  account  management  process  for  the  contractor  and 
the  Navy  Reserve. 

D.  CHAPTER  SUMMARY 

This  chapter  provided  a  detailed  examination  of  the  significant  challenges  and 
concerns  associated  with  account  management.  These  challenges  involve  the  current 
organizational  structure  which  disallows  account  aggregation  or  sharing  between  the 
claimants;  the  lack  of  policy  and  procedural  guidance  for  account  managers  causing  them 
to  create  local  procedures  that  may  not  include  all  areas  of  account  management;  the 
different  types  of  account  creation  (i.e.,  duplicate,  multiple,  and  Inactive  accounts)  that 
causes  excess  chargeable  account  to  the  USN  RC,  and  the  multitude  of  stove-piped  IT 
account  management  systems.  They  have  hindered  the  current  account  management 
process  and  have  made  it  ineffective.  Addressing  these  challenges  and  integrating  the 
systems  would  achieve  an  increase  in  the  benefits  of  the  NMCI  contract  while  creating  a 
more  effective  and  efficient  account  management  process. 

The  next  chapter  provides  a  detailed  analysis  of  the  current  state,  called  the  As-Is, 
of  the  NMCI  account  management  process  across  the  Navy  Reserve.  User  surveys  and  a 
process  to  measure  the  knowledge  in  each  task  were  used  to  determine  the  current  state 
and  the  amount  of  value  each  task  provides  to  the  overall  organization. 
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IV.  THE  CURRENT  PROCESS  OF  ACCOUNT  MANAGEMENT 


A.  INTRODUCTION 

This  chapter  describes  and  analyzes  the  U.S.  Navy  Reserve  Component’s  (USN 
RC)  current  approach  to  managing  accounts.  The  necessity  of  capturing  the  current 
process  was  crucial  before  making  recommendations  on  modifications  to  the  process. 
While  several  methods  were  used  to  identify  the  current  process,  the  theory  of 
determining  the  amount  of  knowledge  required  to  generate  the  outputs  of  the  overall 
process,  and  each  of  the  sub-processes,  proved  beneficial  in  detennining  the  value  that 
each  sub-process  provides  to  account  management.  This  methodology,  called 
Knowledge  Valuation  Analysis  or  Knowledge  Value  Added  (KVA),  measures  the 
amount  of  knowledge  required  to  generate  the  outputs  of  a  process  or  sub-process  in 
common  units  of  measurement. 

This  chapter  provides  a  general  overview  to  Knowledge  Management  (KM),  the 
principles  of  KVA,  the  use  of  KVA  to  perform  Business  Process  Redesign,  and  how  each 
was  used  to  complete  the  research  in  this  thesis.  Additionally,  the  chapter  describes  the 
methodology  used  to  capture  the  detailed  analysis  of  each  sub-process  currently  involved 
in  managing  accounts.  Lastly,  the  chapter  identifies  the  knowledge  levels  currently 
embedded  in  each  sub-process  and  their  relative  comparison  in  the  overall  account 
management  process. 

B.  KNOWLEDGE  MANAGEMENT 

The  fundamental  building  material  and  engine  of  wealth  of  the  modern 
corporation  is  the  creation  and  utilization  of  knowledge.  The  real  challenge  in  the 
Information  Age  is  to  understand  how  to  accelerate  the  conversion  of  knowledge  into 
money  through  understanding  how  to  measure  knowledge  assets.  [Ref.  13]  Knowledge 
has  value  that  must  be  managed  and  invested  just  as  organizations  manage  their  human 
resources,  equipment,  and  financial  resources.  In  many  ways,  it  is  considered  the  most 
valuable  asset  within  an  organization  because  the  knowledge  increases  the  more  it  is  used 
within  a  process.  Oftentimes,  organizations  refer  to  their  organizational  knowledge  as 
“Intellectual  Capital.”  This  term  is  appropriate  because  although  it  may  be  difficult  to 
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assign  organizational  knowledge  a  monetary  value,  it  is  still  an  important  commodity 
nonetheless. 

Many  knowledge  enthusiasts  profess  that  the  idea  of  managing  the  knowledge  in 
an  organization  has  begun  to  surpass  common  business  strategies  of  managing 
investment  capital.  The  onset  of  the  knowledge  era  and  the  evolution  from  the  Industrial 
Age  to  the  Information  Age  has  caused  a  progression  in  management  that  shifts  the  focus 
from  managing  people  to  managing  intellectual  capital.  This  transfonnation  has  caused 
many  companies  to  realize  that  their  success  is  contingent  upon  how  successful  they  are 
at  managing  the  knowledge  within  their  organization.  Organizations  are  constantly 
finding  ways  to  capture  and  share  knowledge  effectively  and  efficiently  as  a  means  of 
creating  value  and  reducing  costs  within  the  business  processes. 

The  field  of  Knowledge  Management  has  sparked  interest  in  many  organizations 
worldwide.  In  simplest  terms,  knowledge  management  can  be  defined  as  the  practice  of 
promoting  the  generation  of  new  knowledge,  the  codification  of  knowledge,  and 
providing  availability  or  transfer  of  that  knowledge  all  to  reap  the  greatest  benefit  (profit) 
from  the  asset.  Knowledge  management  also  entails  the  measurement  of  knowledge. 
Skandia  Corporation,  an  international  insurance  company,  has  begun  to  publish  an 
Annual  Report  supplement  to  its  financial  statement  that  outlines  their  Intellectual 
Capital.  In  their  book  Measuring  and  Managing  Knowledge,  Housel  and  Bell  describe 
knowledge  management  as  a  “way  to  detennine  what  knowledge  should  be  privately  held 
and  how  it  can  be  protected  from  competitors  and  clients.”  [Ref.  14:p.  8]  This  is 
important  as  a  company’s  competitive  advantage,  in  fact,  often  lies  in  its  privately  held 
knowledge. 

With  a  company’s  success  dependent  upon  its  ability  to  manage  and  leverage 
knowledge  assets  effectively,  competitive  focus  has  shifted  from  trying  to  “out-do”  one 
another  to  trying  to  “out-know”  one  another  [Ref.  14].  Enterprises  are  realizing  how 
important  it  is  to  “know  what  they  know”  and  to  be  able  to  make  maximum  use  of  the 
knowledge.  This  knowledge  resides  in  many  different  places  such  as  databases, 
knowledge  bases,  filing  cabinets,  and  in  the  heads  of  employees  and  are  distributed 
across  the  enterprise.  All  too  often  one  part  of  an  enterprise  repeats  work  already  done  by 
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another  part  simply  because  there  has  not  been  careful  tracking  of  organizational 
expertise  or  experiences.  Most  traditional  company  policies  and  controls  focus  on  the 
tangible  assets  of  the  company  and  leave  unmanaged  their  important  intangible 
knowledge  assets.  Knowledge  management  is  forcing  enterprises  to  determine  what  their 
knowledge  assets  and  core  competencies  are  and  how  to  manage  and  make  use  of  these 
assets  to  obtain  maximum  return. 

Success  in  an  increasingly  competitive  marketplace  depends  critically  on  the 
quality  of  knowledge  organizations  apply  to  their  key  business  processes.  For  example, 
the  supply  chain  depends  on  knowledge  of  diverse  areas  including  planning,  raw 
materials,  manufacturing,  and  distribution.  Likewise,  product  development  requires 
knowledge  of  consumer  requirements,  new  science,  new  technology,  marketing  etc. 
[Ref.  15]  Achieving  success  is  accompanied  by  many  challenges  that  can  dictate  whether 
an  organization  maintains  or  gains  the  competitive  advantage. 

The  challenge  of  deploying  the  knowledge  assets  of  an  organization  to  create  a 
competitive  advantage  becomes  more  crucial  as  [Ref.  15]: 

•  The  marketplace,  at  the  local  and  global  levels,  is  increasingly  competitive 
and  the  rate  of  innovation  is  rising,  so  that  knowledge  must  evolve  and  be 
assimilated  at  an  ever-increasing  rate. 

•  Corporations  are  organizing  their  businesses  to  be  focused  on  creating 
customer  value.  Staff  functions  and  management  structures  are  being 
reduced.  There  is  a  need  to  replace  the  informal  knowledge  management 
of  the  staff  function  with  formal  methods  in  customer  aligned  business 
processes. 

•  Competitive  pressures  are  reducing  the  size  of  the  workforce  which  holds 
this  knowledge. 

•  Knowledge  takes  time  to  experience  and  acquire  while  employees  have 
less  time  to  gain  the  experience  and  acquire  the  knowledge. 

•  There  is  a  need  to  manage  increasing  complexity  as  changes  in  strategic 
direction  may  result  in  the  loss  of  knowledge  in  a  specific  area. 
Subsequent  reversal  in  policy  may  then  lead  to  renewed  requirements  for 
this  knowledge  but  the  employees  possessing  that  knowledge  may  no 
longer  exist  within  the  organization. 

1.  Knowledge  in  the  Context  of  Knowledge  Management 

While  many  definitions  exist  for  knowledge,  there  is  still  a  level  of  complexity  in 

understanding  the  manner  in  which  it  can  be  employed  in  the  various  fields  of  study.  To 
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implement  knowledge  management  successfully  within  an  organization,  the  managers 
must  be  able  to  define  knowledge  before  they  can  begin  to  manage  it. 

At  issue  is  the  definition  of  knowledge  management  and  the  component  concepts. 
Thomas  Davenport,  in  discussing  knowledge  management  and  related  concepts,  has 
presented  the  following  ideas  [Ref.  16]. 

Data  are  a  set  of  objective  facts  about  events  or  structured  records  of  transactions. 
These  records  may  give  quantity,  cost,  color,  size,  but  usually  fail  to  record  why  the 
purchase  was  made,  how  likely  it  is  a  repeat  purchase,  request  for  a  service,  or  the 
occurrence  of  an  event. 

Information  on  the  other  hand  is  “usually  in  the  form  of  a  document  or  an 
audible  or  visible  communication.  Information  has  a  sender  and  receiver  and  is  intended 
to  change  the  way  the  receiver  perceives  something.  “ It's  data  that  makes  a  difference 
Information  moves  around  organizations  through  hard  networks  with  visible  and  definite 
infrastructure,  wires,  delivery  vans,  satellite  dishes,  post  offices,  addresses,  electronic 
mailboxes  and  soft  networks  or  informal  networks  often  invisible  and  less  formal. 

Knowledge  is  usually  recognized  as  broader,  deeper  and  richer  than  data  or 
information.  Davenport  and  Prusak  define  knowledge  as: 

a  fluid  mix  of  framed  experience,  values  contextual  information,  and 

expert  insight  that  provides  a  framework  for  evaluating  and  incorporating 

new  experiences  and  infonnation.  It  originates  and  is  applied  in  the  minds 

of  knowers. 

In  organizations,  knowledge  often  becomes  embedded  not  only  in  documents  or 
repositories  but  also  in  organizational  routines,  processes,  practices,  and  norms. 

Knowledge  assets  are  the  tacit  and  explicit  knowledge-creating  objects  such  as 
markets,  products,  technologies,  and  organizations  that  a  business  owns  or  needs  to  own 
and  which  enable  its  business  processes  to  generate  profits,  add  value,  etc.  Explicit 
knowledge  is  that  which  has  been  easily  articulated  and  is  simple  to  transfer  from  one 
person  to  another.  Nonaka  and  Takeuchi  state  that  it  can  be  expressed  in  words  and 
numbers,  and  easily  communicated  and  shared  in  the  form  of  hard  data,  scientific 
formulae,  or  codified  procedures  [Ref.  18].  It  is  easy  to  codify  and  can  normally  be  found 
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shared  in  documents,  databases,  and  other  tangible  media.  Examples  of  explicit 
knowledge  include  chemical  formula,  market  forecasts,  software  code,  and  technical 
standards.  Conversely,  tacit  knowledge  has  an  increased  level  of  difficulty  when  trying 
to  capture  and  share  it  because  it  is  subconsciously  understood  and  developed  from  direct 
experience  and  action  [Ref.  19].  Tacit  knowledge  is  “deeply  rooted  in  an  individual’s 
action  and  experience,  as  well  as  in  ideals,  values  or  emotions:  that  have  developed 
within  an  individual.”  [Ref.  18]  Knowledge  management  is  not  only  about  managing 
these  knowledge  assets  but  also  about  managing  the  processes  that  act  upon  the  assets. 
These  processes  include  developing  knowledge;  preserving  knowledge;  using  knowledge, 
and  sharing  knowledge. 

Therefore,  Knowledge  Management  involves  the  identification  and  analysis  of 
available  and  required  knowledge  assets,  knowledge  asset-related  processes,  and  the 
subsequent  planning  and  control  of  actions  to  develop  both  the  assets  and  the  processes 
so  as  to  fulfill  organizational  objectives.  Knowledge  management  is  not  only  about 
managing  these  knowledge  assets  but  managing  the  processes  that  act  upon  the  assets. 
These  processes  include  developing  knowledge;  preserving  knowledge;  using,  and 
sharing  knowledge. 

Although  some  writers  like  Karl-Erik  Sveiby  define  knowledge  management  as 
“the  art  of  creating  value  from  intangible  assets”  [Ref.  20],  implementation  of  knowledge 
management  in  fact  involves  activities  in  information  management,  information 
technology,  and  human  resources  development.  Component  activities  of  knowledge 
management  have  been  undertaken  by  librarians  and  other  information  professionals, 
educators,  database  administrators  and  other  information  technology  personnel. 

What  then  makes  the  difference  between  the  normal  activities  of  these 
professionals  and  ventures  into  knowledge  management?  An  important  factor  is  the 
emphasis  on  achieving  organizational  strategies,  and  the  consequent  need  for  cultural 
change,  increased  teamwork,  integration  of  content  and  information  technologies  and 
continuing  development  of  related  organizational  policies. 
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2.  The  Role  of  Information  Technology  in  Knowledge  Management 

The  concept  of  treating  organizational  knowledge  as  a  valuable  strategic  asset  has 
been  popularized  by  leading  management  and  organization  theorists.  Organizations  are 
being  advised  that  to  remain  competitive,  they  must  efficiently  and  effectively  create, 
locate,  capture,  and  share  their  organization’s  knowledge  and  expertise.  They  must  also 
demonstrate  the  ability  to  bring  that  knowledge  to  bear  on  problems  and  opportunities. 

Although  knowledge  management  is  becoming  widely  accepted,  few 
organizations  are  fully  capable  of  developing  and  leveraging  critical  organizational 
knowledge  to  improve  their  performance  [Ref.  19].  Many  organizations  have  become  so 
complex  that  their  knowledge  is  fragmented,  difficult  to  locate  and  share,  and  therefore, 
redundant,  inconsistent  or  not  used  at  all.  In  today’s  environment  of  rapid  change  and 
technological  discontinuity,  even  knowledge  and  expertise  that  can  be  shared  is  often 
quickly  made  obsolete.  The  reach  of  know-how  and  experience  possessed  by  individuals 
can  be  greatly  extended  once  it  is  captured  and  explicated  so  that  others  can  easily  find, 
understand  and  use  it. 

The  information  technology  infrastructure  should  provide  a  seamless  “pipeline” 
for  the  flow  of  explicit  knowledge  to  enable  [Ref.  19]: 

•  Capturing  knowledge 

•  Defining,  storing,  categorizing,  indexing  and  linking  digital  objects 
corresponding  to  knowledge  units; 

•  Searching  for  (“pulling”)  and  subscribing  to  (“pushing”)  relevant  content, 

•  Presenting  content  with  sufficient  flexibility  to  render  it  meaningful  and 
applicable  across  multiple  contexts  of  use. 

The  focus  is  on  the  technologies  that  capture,  store,  and  distribute  structured 
knowledge  for  use  by  people.  The  goal  of  these  technologies  is  to  take  knowledge  that 
exists  in  human  heads  and  paper  documents,  and  various  disparate  systems  and  media, 
and  make  it  widely  available  throughout  an  organization  [Ref.  17].  Information 
technologies  such  as  the  World  Wide  Web  offer  a  potentially  useful  environment  within 
which  to  build  a  multimedia  repository  for  rich,  explicit  knowledge.  Input  is  captured  by 
forms  for  assigning  various  labels,  categories,  and  indices  to  each  unit  of  knowledge.  The 
structure  is  flexible  enough  to  create  knowledge  units,  indexed  and  linked  using 
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categories  that  reflect  the  structure  of  the  contextual  knowledge  and  the  content  of  factual 
knowledge  of  the  organization,  displayed  as  flexible  subsets  via  dynamically 
customizable  views. 

Effective  use  of  information  technology  to  communicate  knowledge  requires  an 
organization  to  share  an  interpretive  context.  The  more  that  communicators  share  similar 
knowledge,  background  and  experience,  the  more  effectively  knowledge  can  be 
communicated  via  electronically  mediated  channels  [Ref.  23].  Michael  Zack  stated  in  his 
research  in  Managing  Codified  Knowledge  that  at  one  extreme,  the  dissemination  of 
explicit,  factual  knowledge  within  a  stable  community  having  a  high  degree  of  shared 
contextual  knowledge  can  be  accomplished  through  access  to  a  central  electronic 
repository  [Ref.  19].  However,  when  interpretive  context  is  moderately  shared,  or  the 
knowledge  exchanged  is  less  explicit,  or  the  community  is  loosely  affiliated,  then  more 
interactive  modes  such  as  electronic  mail  or  discussion  databases  are  appropriate.  When 
context  is  not  well  shared  and  knowledge  is  primarily  tacit,  communication  and  narrated 
experience  is  best  supported  with  the  richest  and  most  interactive  modes  such  as  video 
conferencing  or  face-to-face  conversation  [Ref.  19]. 

In  understanding  the  role  of  IT  in  knowledge  management,  it  is  important  to 
emphasize  that  IT  is  an  enabler  of  knowledge  management  rather  than  a  driver. 
Subsequently,  IT  is  only  the  pipeline  and  storage  system  for  knowledge  exchange.  It 
does  not  create  knowledge  and  cannot  guarantee  or  even  promote  knowledge  generation 
or  knowledge  sharing  in  an  organizational  culture  that  does  not  favor  those  activities 
[Ref.  17].  Technology  alone  will  not  force  a  person  with  expertise  to  share  it  with  others. 
While  technology  is  common  in  the  domain  of  knowledge  distribution,  it  rarely  enhances 
the  process  of  knowledge  use.  Extensive  behavioral,  cultural,  and  organizational  change 
could  cause  a  positive  environment  that  would  encourage  knowledge  use. 

IT  is  also  relatively  less  helpful  when  it  comes  to  knowledge  creation,  which 
remains  largely  an  act  of  individuals  or  groups  and  their  brains  [Ref.  17].  Housel  and 
Bell  further  highlight  this  by  offering  two  principals  that  could  make  moving  knowledge 
assets  advantageous.  First,  simple  and  procedural  knowledge  that  is  employed  frequently 
should  be  moved  to  IT.  Relocating  procedural  knowledge  like  assembly  line 
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manufacturing  to  IT  drastically  decreases  the  cost  per  usage  of  each  unit  of  knowledge 
utilized.  Second,  organizations  should  seek  to  capture  in  IT  the  knowledge  that  typically 
dies  when  an  employee  leaves  the  company.  The  complex  or  tacit  knowledge  that  an 
employee  accumulates  with  years  of  experience  is  often  indispensable  and  should  be 
captured  in  IT  to  ensure  continued  operations.  Capturing  the  knowledge  in  IT  ensures  the 
knowledge  remains  embedded  throughout  the  processes  and  is  accessible  to  any  new 
process  owners.  While  many  organizations  desire  to  capture  this  tacit  knowledge 
embedded  in  the  heads  of  its  employees  to  gain  or  maintain  the  competitive  advantage, 
providing  such  knowledge  is  left  to  the  discretion  of  the  employee  and  should  be 
voluntarily  provided  without  a  violation  of  rights. 

C.  KNOWLEDGE- VALUE  ADDED 

The  fundamental  building  material  of  a  modern  corporation  is  knowledge.  Housel 
and  Kanevsky  [Ref.  13]  state  that  the  engine  of  wealth  in  today’s  business  economy  is  the 
creation  and  utilization  of  knowledge.  Understanding  how  to  accelerate  the  conversion 
of  knowledge  into  money  is  one  of  the  many  challenges  in  the  Information  Age.  This 
‘knowledge  payoff  occurs  when  an  organization’s  most  valuable  intangible  asset  - 
knowledge-  is  converted  into  bottom  line  value  in  the  form  of  concrete,  saleable  products. 

The  knowledge  embedded  in  an  organization’s  structure  (processes,  technology, 
and  people)  is  the  genome  that  represents  the  code  required  for  reproducing 
organizational  products.  This  ‘code’  is  virtually  equivalent  to  the  value  added  by  the 
organization  because  it  is  what  is  necessary  and  sufficient  to  reproduce  the  organization’s 
products  and  services  [Ref.  13]. 

It  has  been  often  stated  that  you  cannot  manage  what  you  cannot  measure.  This 
notion  has  its  roots  in  the  understanding  that  a  system  requires  feedback  to  keep  it  on 
track.  What  managers  monitor  and  measure  determines  what  feedback  they  obtain  and 
how  well  their  systems  are  geared  to  achieving  their  goals.  The  basic  goal  for  monitoring 
and  measuring  knowledge  is  to  detennine  how  well  it  is  producing  value  in 
organizational  processes.  This  requires  following  the  use  of  knowledge  throughout  an 
organization’s  core  processes  and  its  interactions  with  the  marketplace. 
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Drs.  Housel  and  Kanevsky  recognized  the  need  for  an  objective  means  for 
measuring  organizational  knowledge  in  common  units  and  developed  a  methodology 
called  knowledge-value  added  (KVA)  to  do  this.  KVA  helps  managers  understand  how 
to  best  leverage  the  knowledge  resident  in  employees,  infonnation  technology,  and  core 
processes.  The  essence  of  KVA  is  that  the  knowledge  utilized  in  core  processes  to 
generate  organizational  outputs  can  be  translated  into  numerical  form  as  a  common  unit 
of  measure.  This  translation  provides  an  indication  of  the  value  added  by  process 
knowledge  and  allows  allocation  of  a  benefit  stream  to  that  knowledge.  Tracking  the 
conversion  of  knowledge  into  value,  while  measuring  its  bottom-line  impact,  enables 
managers  to  increase  the  productivity  of  critical  assets. 

Simply  stated,  KVA  can  be  defined  as  a  new  method  of  gathering  historical  data 
about  the  outputs  of  an  organization’s  processes.  These  new  data  are  described  in  a 
common  unit  of  measure  that  reflects  the  amount  of  organizational  knowledge  required  to 
produce  the  outputs.  Once  organizational  knowledge  has  been  quantified  using  KVA,  it 
can  be  monetized  and  used  in  common  performance  ratios  such  as  ROI  and  in  new  ratios 
such  as  knowledge  in  use  compared  to  knowledge  in  inventory  or  knowledge  in  people 
compared  to  knowledge  in  IT.  KVA  can  also  be  used  to  develop  estimates  of  price  per 
unit  of  knowledge  as  well  as  cost  per  unit  of  knowledge,  using  either  monetized  or  non- 
monetized  common  units. 

1.  KVA  Theory 

In  order  to  understand  the  concepts  of  KVA,  it  is  important  to  understand  the 
KVA  value-adding  cycle  and  the  fundamental  assumptions  where  it  derives  its  validity  as 
a  knowledge  measurement  method.  See  Figure  7. 
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P(x)  =  y 

Process  P  is  a  business  process. 

If  input  x  is  equal  to  output  y,  no  value  has  been  added  by  process  P. 

If  input  .y  is  changed  by  process  P  into  output  y,  value  has  been  added  and  is  ~  change. 

Change  can  be  measured  by  the  amount  of  knowledge  required  to  make  the  change. 

This  knowledge  ~  the  amount  of  time  it  takes  for  an  average  learner  to  acquire  the  knowledge. 

So,  value  added  by  process  ~  change  ~  knowledge  required  to  produce  the  outputs 

Housel,  T.  &  Kanevsky,  V.  (1995)  “Reengineering  Business  Processes:  A  Complexity  Theory  Approach  to 

Value  Added,”  INFOR  33(4):  25 1 . 

Figure  7.  Fundamental  Assumption  of  KVA  (From:  Ref.  13). 

Figure  7  illustrates  these  assumptions. 

•  In  any  process,  there  is  an  input,  a  process  that  changes  the  input,  and  an 
output. 

•  If  the  input  is  equal  to  the  output,  then  the  process  adds  no  value. 

•  If  a  process  produces  an  output  that  is  different  from  the  input,  then  the 
amount  of  change  is  proportional  to  the  amount  of  value  added  by  the 
process.  The  “change”  that  takes  place  during  the  process  is  what  creates 
value. 

•  Change  can  be  discussed  in  terms  of  the  amount  of  knowledge  that  it  takes 
to  produce  that  change. 

•  Therefore,  there  exists  a  proportional  relation  between  value  and  the 
knowledge  required  to  make  change. 

By  accepting  the  assumption  that  knowledge  and  change  are  proportional,  it  is 
then  possible  to  use  knowledge  as  a  surrogate  for  value  when  assessing  process  units  of 
outputs.  Once  the  units  of  outputs  are  standardized  into  a  common  unit  of  measure,  the 
knowledge,  then  is  it  feasible  to  make  beneficial  comparisons  across  multiple  processes. 

2.  How  KVA  Works 

What  makes  KVA  a  powerful  tool  is  that  it  can  be  relatively  simply  defined  in 

three  different  approaches,  yet  it  is  robust  enough  to  produce  a  desired  level  of  detail 

should  managers  desire  a  more  comprehensive  view  of  the  organizational  processes. 
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Housel  and  Bell  have  defined  three  different  ways  to  establish  the  value  of  knowledge 
embedded  in  the  IT  systems  and  the  people  within  an  organization.  See  Figure  8. 
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Describe  the  products  in  terms 
of  the  instructions  required  to 
reproduce  them  and  select  unit 
ol  process  description. 

Create  a  set  of  binary  yes/no 
questions  such  that  all  possible 
outputs  are  represented  as  a 
sequence  of  yes/no  answers. 

3. 

Calculate  learning  time  to 
execute  each  subprocess. 

Calculate  numbor  of  process 
instructions  pertaining  to 
each  subprocess. 

Calculate  length  of  sequence  of 
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4. 
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each  subprocess  by  the  number 
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string  lor  each  subprocess  by  the 
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Allocate  revenue  to  subprocesses  in  proportion  to  the  quantities  generated  by  step  5  and  calculate 
costs  for  each  subprocess. 

7. 

Calculate  ROK,  and  Interpret  the  results. 

Figure  8.  Three  Approaches  to  KVA  (From:  Ref.  14). 


Figure  8  summarizes  each  approach. 

•  Learning  Time:  Learning  time  measures  how  long  it  takes  an  “average 
learner”  to  leam  a  function  or  process.  Once  the  learning  time  has  been 
determined,  it  is  then  multiplied  by  the  number  of  times  that  function  is 
performed  over  a  predetermined  period  of  time. 

•  Process  description:  Describes  products  relative  to  the  number  of 
instructions  required  to  reproduce  them.  Once  the  number  of  instructions 
has  been  detennined,  it  is  then  multiplied  by  the  number  of  times  the 
process  executes. 

•  Binary  Query  Method:  Creates  a  set  of  binary  yes/no  questions  such  that 
all  possible  outputs  are  represented  as  a  sequence  of  yes/no  answers. 
Once  the  answers  have  been  collected,  multiply  the  length  of  the  yes/no 
string  for  each  of  the  sub-processes  by  the  number  of  times  the  sub¬ 
process  was  executed. 

While  Housel  and  Bell  states  that  the  Binary  Query  Method  is  the  most  accurate 
approach  to  doing  KVA,  it  is  also  the  most  tedious  and  is  most  suitable  for  processes  that 
require  the  highest  degree  of  accuracy  and  granularity.  This  thesis  utilizes  the  Learning 
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Time  method  to  calculate  the  Return  on  Knowledge  (ROK)  for  the  Navy  Reserve 
Account  Management  process. 

3.  Return  on  Knowledge 

Industry  has  traditionally  used  ratio  analysis  to  assist  with  detennining  and 
measuring  a  company’s  profitability  and  performance.  One  such  ratio,  commonly  used 
by  industry,  is  Return  on  Investment  (ROI).  ROI  indicates  how  many  dollars  of  profit  are 
generated  by  each  dollar  of  cost.  It  is  used  to  help  organizations  make  capital  investment 
decisions,  initiate  future  business  solutions,  and  select  the  best  course  of  action.  While 
many  benefits  can  be  achieved  by  using  ROI  analysis,  it  falls  short  in  the  ability  to  reflect 
indirect  costs  and  fluctuating  returns  accurately  over  time.  The  ROI  is  calculated  by 
considering  the  annual  benefit  stream  (or  profit)  divided  by  the  cost  associated  with  the 
benefit  stream.  The  equation  is  simply: 

Revenue  -  Cost  of  Investment  _  Net  Benefit 
Cost  of  Investment  Total  Cost 

While  commercial  industry  has  reaped  benefits  in  using  ROI,  such  an  analysis  is 
difficult  for  not-for-profits  such  as  the  Department  of  Defense  (DoD),  in  which  a 
traditional  “revenue  stream”  is  not  generated.  Rather  than  using  some  extrapolation  of 
cost  in  place  of  a  revenue  stream  (for  example,  cost  savings),  KVA  can  assist  DoD  to 
measure  and  allocate  a  proxy  for  revenue  that  will  enable  it  to  determine  the  value  of  its 
knowledge-base  assets  (people,  processes,  and  technology)  that  cannot  be  reflected  in 
traditional  ROI  methodologies.  KVA  data  populates  a  new  ratio,  Return  on  Knowledge 
(or  ROK),  which  describes  “returns”  in  terms  of  the  number  of  units  of  knowledge  that 
are  generated  by  each  unit  of  knowledge  cost.  Using  Learning  Time  as  a  surrogate  for 
the  return  in  ROI,  the  ROK  ratios  can  now  be  defined  as: 

ROK  =  — 

c 


where: 

K  =  Knowledge  generated  by  a  single  core  process 

C  =  Cost  assigned  to  Time  to  Complete  a  single  core  process,  or  surrogate  for  cost 
assigned 
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D.  BUSINESS  PROCESS  REDESIGN 


Business  Process  Redesign  (BPR)  has  had  a  major  impact  on  organizations  that 
have  desired  to  make  changes  in  their  organizational  processes  to  achieve  higher  levels  of 
effectiveness  and  efficiency.  The  concept  of  BPR  as  a  strategy  to  make  modifications 
within  organizational  business  processes  began  its  history  in  the  1980’s.  At  that  time, 
investments  in  IT  did  not  result  in  corresponding  improvements  or  increases  in 
productivity  and  perfonnance.  Many  explanations  were  given  as  to  why  IT  did  not 
produce  the  results  that  were  expected.  Some  blamed  the  IT  and  such  things  as  the  way  it 
was  being  implemented,  the  user-unfriendly  nature  of  software,  the  lack  of  managerial 
understanding  of  IT  (called  technophobic),  the  lack  of  information  systems 
professionals  understanding  of  business  (called  technocentric),  and  faulty  implementation 
of  IT  [Ref.  22]. 

Years  of  continued  failure  of  IT  investments  caused  business  to  shift  its  focus. 
They  began  to  realize  that  perhaps  the  IT  systems  were  not  to  blame,  but  rather  that 
organizational  processes,  structures  and  designs  were  not  work-friendly.  They  realized 
that  applying  IT  to  traditional  hierarchical  structures,  complex  procedures,  and  antiquated 
organizational  designs  exacerbated  the  problems,  and  that  automating  them  with  IT 
cemented  complex  archaic  structures  through  automation  rather  than  improved  them  (El 
Sawy,  2001).  This  approach  of  applying  IT  to  existing  problems  is  simply  an  exercise  in 
paving  the  cowpath5. 

As  the  competition  begin  to  ramp  up,  many  scholars  began  to  research  ways  in 
which  organizations  could  achieve  faster  cycle  times,  cost  cutting,  and  improvements  in 
customer  responsiveness.  The  overwhelming  desire  was  to  find  ways  of  performing 
business  that  would  yield  exponential  increases  in  perfonnance.  These  scholars 
concluded  that  the  demands  could  only  be  met  by  rethinking  how  business  is  performed 
and  by  taking  advantage  of  the  capabilities  of  IT.  Hence,  the  BPR  concept  began  to  take 
industry  by  storm. 


5  Paving  the  cowpath  refers  back  to  the  early  part  of  this  century,  when  people  simply  paved  the 
traditional  serpentine  roads  needed  for  animal-based  transportation,  rather  than  re-routing  roads  directly 
over  the  hill  to  take  advantage  of  powerful  automobile  technology.  In  Information  Technology,  it  refers  to 
automating  inefficient  processes  thus  creating  more  inefficiency. 
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1.  BPR  Defined 

In  order  to  understand  BPR  fully,  first  it  is  necessary  to  determine  the  definition 
of  a  business  process.  Davenport  and  Short  (1990)  define  a  business  process  as  “a  set  of 
logically  related  tasks  performed  to  achieve  a  defined  business  outcome.”  It  implies  a 
strong  emphasis  on  how  work  is  performed  within  an  organization.  In  their  view, 
processes  have  two  important  characteristics:  1)  They  have  customers  (internal  or 
external)  and  2)  They  cross  organizational  boundaries  (i.e.,  they  occur  across  or  between 
organizational  subunits).  Processes  are  generally  identified  in  tenns  of  beginning  and 
end  point,  interfaces,  and  organization  units  involved,  particularly  the  customer  unit. 
Conversely,  El  Sawy  (2001)  defines  a  business  process  by  breaking  down  the  letters  in 
the  BPR  acronym.  He  states  that  the  focus  is  on  end-to-end  business  processes  that 
extend  to  the  customer  the  value  of  the  process.  He  further  indicates  that  the  ‘B’  “defines 
the  boundaries  of  a  process  in  a  way  that  makes  sense  in  terms  of  business  value:  the 
coordination  of  ensembles  of  tasks  perfonned  by  many  people  rather  than  narrow  tasks 
performed  by  one  person.”  The  ‘P’  in  BPR  has  a  “primary  focus  on  essential  processes 
that  deliver  outcomes  is  the  signature  of  all  variants  of  BPR  rather  than  a  focus  on  static 
organizational  structures.”  It  looks  primarily  at  dynamic  process  flows  that  move  rather 
than  static  organizations  structures.  It  is  cross-functional  in  scope  within  an  enterprise. 
He  states  that  it  is  a  coordinated  and  logically  sequenced  set  of  work  activities  and 
associated  resources  that  produce  something  of  value  to  a  customer  (El  Sawy,  2001). 
While  the  definitions  of  a  business  process  given  by  Davenport  and  El  Sawy  differ,  both 
indicate  that  a  process  must  have  boundaries,  relationships,  and  create  an  output.  By 
examining  the  definition  of  a  business  process,  a  clearer  understanding  of  BPR  can  now 
be  gained. 

Much  has  been  written  about  the  concept  in  both  the  practitioner  trade  press  and 
in  academic  research,  yet  finding  a  common  definition  of  BPR  has  become  an  impossible 
task.  Davenport  and  Short  has  defined  BPR  as  “the  analysis  and  design  of  workflows  and 
processes  within  and  between  organizations”  [Ref.  21].  El  Sawy  provides  a  more 
comprehensive  definition  as  he  states  that  BPR  is  a  performance  improvement 
philosophy  that  aims  to  achieve  quantum  improvements  by  primarily  rethinking  and 
redesigning  the  way  business  processes  are  executed  [Ref.  22], 
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2.  The  Use  of  IT  and  BPR 

While  both  of  these  definitions  slightly  vary  in  meaning  and  in  interpretation, 
both  authors  agree  that  the  use  of  IT  is  the  key  enabler  of  BPR.  Davenport  and  Short 
argued  that  BPR  requires  taking  a  broader  view  of  both  IT  and  business  activity,  and  of 
the  relationships  between  them.  IT  should  be  viewed  as  more  than  an  automating  or 
mechanizing  force  to  fundamentally  reshape  the  way  business  is  done.  They  believe  that 
business  activities  should  be  viewed  as  more  than  a  collection  of  individual  or  even 
functional  tasks  in  a  process  view  for  maximizing  effectiveness.  IT  and  BPR  have  a 
recursive  relationship.  IT  capabilities  should  support  business  processes,  and  business 
processes  should  be  in  terms  of  the  capabilities  IT  can  provide.  Davenport  and  Short 
(1990)  refer  to  this  broadened,  recursive  view  of  IT  and  BPR  as  the  new  industrial 
engineering. 

El  Sawy  indicates  that  the  success  of  BPR  is  not  solely  reliant  on  the  redesign  of 
business  processes.  He  states  that  the  work  environment  around  the  business  process 
may  require  some  adjustments.  He  uses  the  Leavitt  Diamond  structure  shown  below  to 
demonstrate  this  theory  and  to  illustrate  how  BPR  fits  into  an  organization.  Harold  J. 
Leavitt  developed  the  Leavitt  Diamond  (Figure  9)  to  demonstrate  the  relationships 
between  four  key  functions  of  the  BPR  initiative.  Managing  the  organizational  variables 
of  IT  use,  organizational  fonn,  requisite  people  skills,  and  business  processes  is 
imperative  to  ensure  that  the  organization  maintains  the  balance  required  for  BPR 
success.  For  example,  if  a  new  IT  is  introduced  into  the  organization,  business  processes 
may  need  to  be  changed  to  take  advantage  of  the  technology.  The  use  of  the  new  IT  and 
the  newly  designed  process  may  require  new  people  skills  to  match,  and  perhaps  a  new 
organizational  form  (more  centralized,  or  team-based,  for  example)  [Ref.  22]. 
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Figure  9.  The  Leavitt  Diamond. 

Understanding  such  a  framework  is  critically  important  when  redesigning 
processes  that  are  knowledge  intensive.  As  processes  change  and  the  remaining  variables 
in  the  Leavitt  Diamond  are  affected,  changes  in  the  knowledge  that  surrounds  the  process 
will  likely  change  dynamically.  It  either  departs  with  outgoing  personnel  or  becomes 
useless  because  it  resides  in  the  heads  of  personnel  who  have  been  disassociated  with  the 
process.  Thus,  when  redesigning  processes,  it  is  imperative  to  ensure  that  the  knowledge 
about  the  process  is  considered  and  captured  in  the  IT  where  feasible. 

3.  Phases  of  BPR 

Table  1  and  Figure  10  depict  the  phases  of  BPR,  as  defined  by  El  Sawy,  and  what 
actions  are  completed  in  each  phase.  [Ref.  22]  While  this  thesis  focuses  only  on  the  first 
two  phases,  it  is  important  to  note  that  proper  execution  of  Phase  3  is  imperative  in  order 
to  make  the  BPR  IT  solution  successful.  Figure  10  illustrates  that  the  foundation  for  the 
success  of  the  process  redesign  model  is  the  requirement  to  share  process  knowledge. 
The  sharing  of  this  knowledge  is  required  within  each  phase  of  the  BPR  cycle.  Table  1 
provides  each  of  the  phases  and  the  activities  that  accompany  them.  The  information 
contained  within  the  table  provides  enough  high-level  detail  and  little  explanation  of  each 
is  required. 
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Phase  1 

Phase  2 

Phase  3 

Scoping  the  process 

Modeling,  analysis,  and 

Planning  process 

redesign  of  process 

Integration 

Activities 

• 

Operationalize  process 

• 

Continue  data  collection 

•  Provide  workflow  model  or 

performance  targets 

• 

Model  “As-Is"  baseline 

requirements  for  IS  design 

• 

Define  process  boundaries 

process 

•  Adjust  process  design 

• 

Identify  Key  process  Issues 

• 

Analyze  and  diagnose  "As- 

•  Plan  for  process 

• 

M nripr^i^ nd  practices 

Is"  process 

implementation 

and  define  initial  visions 

• 

Design  and  model  “To-Be” 

• 

Outline  data  collection  plan 

process  alternatives 

and  collect  baseline  data 

• 

Analyze  "To-Be"  process 

• 

Plan  for  modeling  phase 

alternatives  and  select  best 
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Customers  of  Process 

• 
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Table  1.  Key  Phases  and  Activities  in  BPR  (From:  Ref.  22). 

The  phases  are: 

•  Phase  1 :  Scoping  phase 

•  This  phase  is  used  to  define  the  inputs  to  the  process  undergoing 
change  and  the  desired  output  to  achieve.  This  phase  keeps  the 
BPR  team  focused  and  on  course  throughout  the  BPR  process. 

•  Phase  2:  Modeling,  Analysis,  and  Redesign  phase 

•  In  this  phase,  a  model  of  the  current  or  “As-Is”  process  is  drafted, 
analysis  of  the  As-Is  is  conducted  and  then  future  process 
alternatives  or  “To-Be”  processes  can  be  modeled,  analyzed  for 
best  performer  and  then  the  plan  for  phase  3.  This  phase  is  the 
focus  of  research  performed  in  this  thesis. 

•  Phase  3:  Planning  Process  Integration  phase 

•  This  phase  is  designated  for  drafting  a  plan  for  integrating  the  new 
process  alternative  for  smooth,  seamless  integration  of  the  new 
process  into  the  current  organization. 
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Figure  10.  Phases  of  Business  Process  Redesign  (From:  Ref.  22). 

A  large  portion  of  the  information  in  this  chapter  was  derived  by  utilizing  the 
processes  included  in  Phase  2.  While  the  KVA  methodology  of  Housel  and  Bell  was 
used  to  capture  the  knowledge  in  each  sub-process,  El  Sawy’s  BPR  phase  approach 
assisted  with  determining  when  the  knowledge  should  be  captured.  The  methodology 
and  theories  of  both  Housel  and  Kavesky  for  KVA  and  El  Sawy  for  BPR  were  used  in 
defining  the  As-Is  and  the  To-Be  for  NMCI  account  management. 

E.  DEFINING  THE  CURRENT  PROCESS  FOR  ACCOUNT  MANAGEMENT 

This  section  provides  the  supporting  research  data  and  shows  how  the  KVA 
methodology  and  BPR  principles  were  used  to  perform  data  collection,  model  the  As-Is 
process,  capture  the  value  added  within  the  process,  and  analyze  and  diagnose  the  current 
NMCI  account  management  process.  All  of  the  core  sub-processes  involved  in  account 
management  were  examined  and  evaluated  against  one  another  to  determine  which  sub¬ 
processes  provided  the  least  return  on  the  knowledge  utilized.  It  was  discovered  during 
the  initial  stages  of  research  that  there  was  no  written  policy  or  guidance  provided  to  the 
customer  technical  representatives  (CTR),  and  therefore,  no  standardized  process  existed 
for  account  management.  For  the  purpose  of  this  thesis,  the  terms  technical 
representative  and  account  manager  are  used  synonymously. 
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1.  Data  Collection 

The  focus  of  the  data  collection  was  to  obtain  information  that  would  prove 
valuable  to  understanding  the  current  process  for  managing  accounts  before  making 
recommendations  on  improvements.  The  researcher  determined  that  using  BPR 
principles  from  El  Sawy  would  prove  to  be  most  beneficial  when  defining  the  current 
process  and  making  recommendations  for  changes  in  the  process. 

While  there  was  no  standardized  process  for  account  management  across  all  of  the 
USN  RC,  the  researcher  expected  to  find  a  common,  standard  process  amongst  the  USN 
RC  regions  of  which  a  good  estimation  could  be  made  to  perfonn  the  KVA  analysis. 
However,  the  research  found  that  there  was  not  even  a  standard  process  amongst  the  USN 
RC  regions.  The  scope  of  the  data  collection  was  limited  to  capturing  the  current  process 
for  USN  RC  account  management.  It  was  assumed  and  verified  through  phone 
interviews  that  capturing  the  account  management  process  for  the  USN  RC  would  likely 
be  a  good  representation  of  the  process  for  the  United  States  Navy  Active  Component 
(USN  AC  )  as  well. 

2.  Collection  Methodology 

To  begin  data  collection,  phone  and  personal  interviews  were  conducted  with  the 
Commander  Navy  Reserve  Force  Command  (CNRFC),  Command  Infonnation  Officer 
(CIO)  to  identify  and  prioritize  his  concerns  with  the  NMCI  account  management  process 
and  their  effect  on  the  USN  RC  organization.  The  purpose  of  the  interviews  was  to  fully 
understand  the  concerns  surrounding  account  management.  The  CIO’s  concerns  were  as 
follows: 

•  That  the  U.S.  Navy  Reserve  Component  should  not  be  paying  for  a 
person’s  account  who  is  no  longer  affiliated  with  the  organization  due  to 
the  following  status: 

•  Deceased,  separated,  retired,  transferred  to  active  duty,  etc. 

•  That  maximum  utilization  should  be  made  of  the  two  free  accounts  that 
accompany  each  unclassified  seat; 

•  That  the  U.S.  Navy  Reserve  Component  should  not  be  paying  for 
duplicate  accounts  (not  to  be  confused  with  valid  multiple  accounts 
required  for  someone’s  job  or  position);  and 
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•  That  the  U.S.  Navy  Reserve  Component  should  not  be  paying  for  an 
account  that  should  be  the  responsibility  of  another  command  outside  of 
RESFOR’s  claimancy. 

While  the  interviews  with  the  CIO  provided  high-level  information  about  the 
USN  RC  concerns,  additional  phone  interviews  were  required  with  the  lead  of  the 
Enterprise  Account  Management  Working  Group  (EAMWG)  to  provide  more  detail 
about  the  account  management  process  and  to  understand  the  business  rules  better.  The 
results  of  the  conference  calls  provided  further  insight  on  the  problems  within  the 
process;  the  high-level  dynamics  of  the  IT  systems  used  for  account  management;  the 
budgeting  process  for  NMCI;  and  a  general  overview  of  some  of  the  major  business 
rules. 

A  follow-on  conference  was  required  with  the  USN  RC  CIO  and  the  subject 
matter  experts  to  clarify  the  account  management  process.  This  call  made  it  possible  to 
glean  information  about  the  vision  for  the  allocation  of  accounts;  the  amount  currently 
spent  on  additional  accounts  (approx.  $35M/year)  that  exceeded  the  total  free  accounts 
that  accompany  a  seat;  the  estimated  total  of  accounts  currently  not  required;  the  use  of 
the  Network  Enterprise  Tool  (NET)  as  the  IT  solution  for  account  and  seat  management; 
the  use  of  eMarketplace  for  budget  reconciliation  and  invoice  validation;  the  role  of  an 
Assistant,  Deputy,  and  primary  Customer  Technical  Representative  (A/D  CTR);  the 
process  for  submitting  a  Move-Add-Change  (MAC)  request;  and  how  Contract  Line  Item 
0024s  (CLIN  24s)  are  determined  and  assigned. 

The  results  of  these  meetings  required  a  clearer  understanding  of  how  account 
management  is  accomplished  at  the  Echelon  III,  IV,  and  V  levels  before  proceeding.  It 
was  decided  that  a  visual  demonstration  of  the  account  management  process  from 
inception  to  completion  was  required  to  completely  understand  the  necessary  actions  in 
account  management  before  designing  the  As-Is  process.  A  visit  to  the  Navy  Reserve 
Center  (NRC),  San  Jose  assisted  in  clarifying  the  numerous  sub-processes.  The  visit 
made  it  possible  to  see  how  the  management  of  accounts  was  performed,  to  view  the 
required  enterprise  IT  systems,  to  review  the  NRC’s  process  and  the  IT  systems  used 
locally;  and  to  capture  the  estimated  time  to  leam  to  perform  each  of  the  sub-processes. 
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The  research  concluded  that,  after  seeing  the  total  lack  of  mandatory  standardized 
sub-processes,  it  would  be  critical  to  create  a  survey  to  sample  a  small  percentage  of 
commands  randomly  from  the  different  RESFOR  regions  and  various  echelons  (ECH)  to 
understand  their  approaches  to  account  management.  The  survey  questions  are  included 
in  Appendix  B.  The  survey  contained  questions  that  would  assist  with  calculating  the 
learning  time,  the  number  of  core  sub-processes  that  are  involved  in  NMCI  account 
management,  the  time  to  execute  each  sub-process,  to  differentiate  between  the  manual 
and  automated  sub-processes;  and  how  many  times  each  sub-process  is  performed  in  a 
week.  A  total  of  thirty-six  commands  were  randomly  selected  to  complete  the  survey. 
The  survey  completion  sample  consisted  of  the  following  commands: 

•  1  CTR  from  CNRFC; 

•  4  Navy  Air  Commands  (3-ECH  IV’s  and  1-ECH  V); 

•  3  REDCOMs  (South,  Mid-Atlantic,  Southwest);  and 

•  28  ECH  V  REDCOM  commands  (4  ECH  V’s  for  each  of  the  7 

REDCOMs) 

While  the  sample  size  consisted  of  thirty-six  commands,  only  thirty-three  of  them 
responded  (91.6%).  A  review  of  the  survey  responses  concluded  that  thirty  of  the  thirty- 
three  responders  provided  data  that  was  useable.  The  survey  successfully  captured 
account  management  trends  across  the  various  regions;  the  time  to  complete  each  sub¬ 
process;  and  the  learning  time  involved  in  each  sub-process. 

3.  The  AS-IS  Process 

Infonnation  collected  during  the  interviews  and  surveys  as  well  as  observation  of 
the  process  during  the  site  visit  made  it  possible  to  devise  several  sub-processes  that 
appeared  to  be  common  across  the  regions  and  formulate  them  into  the  As-Is  model.  The 
purpose  was  to  establish  the  boundaries  between  the  core  scenarios  and  sub-processes 
and  ultimately  use  the  KVA  methodology  to  identify  and  value  the  knowledge  required 
for  each.  While  the  scenarios  specifically  address  DRILLRES  and  FTS,  it  is  assumed 
that  any  of  these  processes  pertain  to  civilian  personnel  as  well.  Figures  1 1-14  depict  four 
unique  scenarios  associated  with  account  management.  Note  that  perforated  lines  around 
any  step  of  the  process  indicate  that  all  technical  representatives  do  not  consistently 
perform  the  process.  The  scenarios  are: 
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•  Drilling  Reservist  (DRILLRES)  or  Full  Time  Support  (FTS)  personnel 
reporting  to  the  Navy  Reserve  Activity  (NRA)  or  from  a  command  not  on 
the  NMCI  network; 

•  DRILLRES  or  FTS  transfers  from  the  current  command  to  another 
command  that  has  cutover  to  NMCI; 

•  DRILLRES  or  FTS  depart  the  USN  RC  by  way  of  retirement,  leaving  the 
USN  RC  for  another  branch  of  service;  and 

•  NRA  overall  seat  and  account  management  process  including  monthly 
account  and  asset  reconciliation. 

F.  “AS-IS”  PROCESS  FLOWCHARTS 

1.  Scenario  1 


Figure  1 1 .  As-Is  Flowchart  When  a  New  DRILLRES/FTS  Reports  for  Duty. 


The  first  scenario  shows  the  process  flow  for  DRILLRES  or  FTS  personnel  that 
are  either  new  to  the  USN  RC  or  that  are  transferring  from  a  non-NMCI  command.  The 
check-in  process  is  as  follows: 

1.  The  User  reports  to  the  command  for  initial  check-in.  Initial  check-in  is 
usually  perfonned  through  a  command  indoctrination  process  or  through 
the  manpower  department.  This  process  is  typically  a  manual  process. 

2.  The  User  in-processes  with  the  NMCI  Account  Manager 
(ACTR/DCTR/CTR)  and  the  manager  make  a  manual  entry  to  a  local 
logbook  for  tracking  purposes. 


48 


3. 


The  technical  representative  annotates  the  User’s  name  and  rate  as  well  as 
the  command  unit  that  the  User  is  assigned  in  the  manual  logbook. 

4.  Once  all  new  Users  are  logged,  the  technical  representative  will  review  the 
check-in  log  and  begin  to  take  action.  There  is  normally  a  significant  time 
lapse  between  when  the  User  was  entered  into  the  logbook  and  when  the 
technical  representative  begins  to  act  upon  the  log  entries  (sometimes  the 
technical  representative  will  wait  until  the  next  business  day  after  a  Drill 
Weekend  (DWE).  In  other  words,  this  step  in  the  process  is  not  routinely 
completed  while  the  User  is  with  the  technical  representative. 

5.  The  technical  representative  will  look  in  the  Global  Address  List  (GAL) 
for  the  User’s  name  annotated  in  the  logbook. 

a.  The  technical  representative  contacts  the  User  if  one  or  more 
names  are  found  in  the  GAL  that  possibly  matches  the  name  of  the 
User.  Time  delay  is  embedded  here,  as  this  process  is  not 
completed  when  the  User  initially  performs  the  check-in  process 
with  the  technical  representative. 

b.  If  one  or  more  of  the  accounts  in  the  GAL  match  the  User,  then  the 
technical  representative  verifies  whether  those  accounts  are 
multiple  accounts  or  duplicate  (i.e.,  excess)  accounts. 

i.  If  the  account(s)  are  verified  to  be  a  duplicate  (or  excess),  a 
MAC  request  is  submitted  to  “move”  one  of  the  accounts  to 
the  new  command  and  a  request  is  submitted  to  “delete” 
any  additional  accounts.  This  request  is  forwarded  by 
completing  a  MS  Word  template  document  and  sending  it 
to  the  authorized  submitter  (or  DCTR)  usually  via  email. 
The  document  is  then  reviewed  by  the  authorized  submitter 
(or  DCTR)  for  accuracy  and  completeness.  The  authorized 
submitter  then  forwards  it  to  the  NMCI  Help  Desk  for 
action.  The  help  desk  forwards  a  confirmation  email  to  the 
authorized  submitter  and  the  initiating  technical 
representatives  once  the  request  has  been  completed.  The 
initiating  technical  representative  will  then  make  a  manual 
entry  in  the  local  logbook  that  includes  the  new  User’s 
account  information. 

c.  If  none  of  the  accounts  in  the  GAL  matches  the  User,  a  MAC 
request  is  submitted  to  “add”  the  user  to  the  NMCI  network.  This 
request  is  forwarded  by  completing  a  MS  Word  template  document 
and  sending  it  to  the  authorized  submitter  (or  DCTR)  usually  via 
email.  The  document  is  then  reviewed  by  the  authorized  submitter 
(or  DCTR)  for  accuracy  and  completeness.  The  authorized 
submitter  then  forwards  it  to  the  NMCI  Help  Desk  for  action.  The 
help  desk  forwards  a  confirmation  email  to  the  authorized 
submitter  and  the  initiating  technical  representatives  once  the 
request  has  been  completed.  The  initiating  technical  representative 
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will  then  make  a  manual  entry  in  the  local  logbook  that  includes 
the  new  User’s  account  information. 


2.  Scenario  2 


Figure  12.  As-Is  Flowchart  When  an  FTS/DRILLRES  Transfers. 


The  second  scenario  shows  the  process  flow  for  DRILLRES  or  FTS  personnel 
that  relocate  from  one  command  on  the  NMCI  network  to  another  command  on  NMCI. 
The  checkout  process  is  as  follows: 

1.  The  User  out-processes  with  the  NMCI  Account  Manager  and  the 
manager  makes  an  entry  into  a  manual  logbook  for  tracking  purposes. 

2.  The  local  technical  representative  contacts  the  gaining  command  of  the 
User  to  have  them  submit  a  MAC  to  “move”  the  existing  account  to  the 
gaining  command. 

3.  The  local  technical  representative  waits  approximately  two  weeks  to  give 
the  gaining  command  time  to  transfer  the  command. 

4.  At  the  end  of  the  two-week  wait  period,  the  local  technical  representative 
checks  the  command’s  Active  Directory  to  confirm  that  the  account  has 
been  transferred. 

a.  If  the  account  is  still  in  the  local  command’s  Active  Directory,  the 
losing  command’s  technical  representative  will  then  submit  a 
MAC  request  to  “deactivate”  the  account.  This  request  is 
forwarded  by  completing  a  MS  Word  template  document  and 
sending  it  to  the  authorized  submitter  (or  DCTR)  usually  via  email. 
The  document  is  then  reviewed  by  the  authorized  submitter  (or 
DCTR)  for  accuracy  and  completeness.  The  authorized  submitter 
then  forwards  it  to  the  NMCI  Help  Desk  for  action.  The  help  desk 
forwards  a  confirmation  email  to  the  authorized  submitter  and  the 
initiating  technical  representatives  once  the  request  has  been 
completed.  The  initiating  technical  representative  will  then  make  a 
manual  entry  in  the  local  logbook  indicating  that  the  action  was 
completed. 


50 


b.  If  confirmation  email,  which  verifies  that  the  action  was 
completed,  is  not  received,  the  losing  command’s  technical 
representative  will  continue  to  check  the  command’s  Active 
Directory  for  a  completed  action.  A  continuation  of  no  action 
prompts  the  technical  representative  to  contact  the  authorized 
submitter  to  check  the  status  of  the  MAC  request.  The  authorized 
submitter  will  then  contact  the  contractor  Service  Request 
Management  (SRM)  team  or  the  help  desk  to  facilitate  the  request. 
This  process  continues  until  the  confirmation  email  is  received 
annotating  that  the  requested  MAC  was  completed. 

3.  Scenario  3 


Figure  13.  As-Is  Flowchart  When  an  FTS/DRILLRES  Retires. 


Scenario  three  illustrates  the  process  flow  for  DRILLRES  or  FTS  personnel  who 
are  retiring,  leaving  military  service,  or  transferring  to  a  non-NMCI  command.  The 
checkout  process  is  as  follows: 

1.  The  technical  representative  receives  a  monthly  command 
termination/modification  form  from  the  administrative  department. 

2.  After  verifying  the  User’s  status,  the  local  technical  representative  submits 
a  MAC  request  to  “deactivate”  the  account. 

3.  This  request  is  forwarded  by  completing  a  MS  Word  template  document 
and  sending  it  to  the  authorized  submitter  (or  DCTR)  usually  via  email. 

4.  The  document  is  then  reviewed  by  the  authorized  submitter  (or  DCTR)  for 
accuracy  and  completeness.  The  authorized  submitter  then  forwards  it  to 
the  NMCI  Flelp  Desk  for  action. 

a.  No  further  action  required  by  the  technical  representative  if  a 
confirmation  email  is  received  stating  that  action  was  completed. 

b.  If  confirmation  email,  which  verifies  that  the  action  was 
completed,  is  not  received,  the  losing  command’s  technical 
representative  will  continue  to  check  the  command’s  Active 
Directory  for  a  completed  action.  A  continuation  of  no  action 
prompts  the  technical  representative  to  contact  the  authorized 
submitter  to  check  the  status  of  the  MAC  request.  The  authorized 
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submitter  will  then  contact  the  contractor  SRM  team  or  the  help 
desk  to  facilitate  the  request.  This  process  continues  until  the 
confirmation  email  is  received  annotating  that  the  requested  MAC 
was  completed. 


4.  Scenario  4 


Figure  14.  As-Is  Flowchart  for  Allocation  of  Accounts  and  Seat  Management. 


Scenario  four  illustrates  the  process  flow  for  overall  management  of  NMCI  seats 
and  accounts.  This  illustration  is  important  to  show  because  is  provides  a  visual  flow  of 
the  various  systems  that  must  be  used  for  daily  account  management.  The  top  process 
flow  is  for  accounts  and  the  bottom  is  for  seats.  The  processes  are  as  follows: 

a.  Accounts 

1.  The  technical  representative  counts  the  number  of  active  accounts  that 
exist  in  the  command’s  Active  Directory.  This  yields  the  total  number  of 
chargeable  accounts  that  should  be  included  on  the  billing  invoice. 

2.  Once  a  month,  the  technical  representative  accesses  eMarketplace  to  view 
the  monthly  invoices. 

3.  A  comparison  is  then  made  with  the  totals  counted  from  the  Active 
Directory  and  the  total  number  of  “free”  accounts  that  are  derived  from 
each  seat  to  determine  the  number  of  CLIN  0024’ s  required. 

4.  The  technical  representative  contacts  the  contractor  to  request 
modifications  to  charges  on  the  billing  invoice  to  reflect  the  actual 
accounts  in  the  Active  Directory. 

b.  Seats 

1.  The  technical  representative  locally  generates  a  CLIN  spreadsheet  that 
contains  a  list  of  all  NMCI  hardware  and  its  physical  location.  This  list  is 
used  to  populate  the  NET  database. 

2.  The  technical  representative  (or  authorized  initiator)  forwards  the 
consolidated  list  via  email  to  the  authorized  submitter  for  review  of 
accuracy  and  completeness. 
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3.  The  authorized  submitter  forwards  the  consolidated  list  for  import  of  data 
into  NET. 

4.  A  seat  identification  (SeatID)  number  is  assigned  to  each  piece  of  NMCI 
standalone  hardware.  The  SeatID  is  a  NET  generated  number  assigned  to 
each  seat  entered  into  the  NET  database.  Every  asset  considered  a  seat  in 
NET  is  assigned  a  SeatID.  Any  peripherals  attached  to  a  seat  do  not  have 
its  own  SeatID,  but  any  peripheral  that  is  ordered  as  stand  alone  hardware 
is  given  its  own  SeatID. 

G.  KNOWLEDGE  VALUE  ADDED  IN  AN  NMCI  ENVIRONMENT 

1.  Time  Required  to  Learn  a  Process 

Time  and  resource  constraints  dictated  the  use  of  the  Learning  Time  methodology 
to  calculate  the  KVA  for  NMCI  account  management.  In  this  method,  the  amount  of 
knowledge  embedded  in  a  process  is  represented  as  the  amount  of  time  necessary  for  an 
average  person  (i.e.,  a  common  reference  point,  “learner”)  to  leam  how  to  complete  the 
process  correctly.  Since  the  researcher  was  unable  to  compare  results  to  those  of  the 
process  description  or  binary  query  method,  the  researcher  used  correlation  between  the 
nominal  learning  time  (NLT)  and  actual  learning  time  (ALT)  to  determine  the  reliability 
of  the  estimate:  The  terms  are  described  below. 

•  Actual  Learning  Time  -  is  the  estimated  time  required  for  the  average 
person  to  leam  each  core  process.  It  answers  the  question  of  how  long  it 
would  take  to  train  someone  to  perform  each  sub-process.  It  represents 
the  value  created  in  each  of  the  sub-process  and  calculated  in  the 
numerator  of  the  ROK  formula.  The  ALT  numbers  were  calculated  from 
site  visits  and  phone  interviews. 

•  Nominal  Learning  Time  -  is  a  second  estimate  of  the  knowledge  required 
to  perform  the  core  processes  and  is  obtained  from  a  second  source.  It  is  a 
measure  of  time  it  takes  to  learn  each  sub-process  given  only  100  total 
hours  to  complete  learning  of  all  sub-processes.  For  instance,  sub-process 
“Create  Add  User  to  User  Log”  requires  the  average  learner  to  use  .5 
hours  learning  time  out  of  a  total  of  100  hours. 

Housel  and  Bell  state  that  the  goal  of  using  both  estimation  methods  is  to  obtain  a 
correlation  of  80%  or  higher  between  them.  A  lower  correlation  would  indicate  one  of 
the  estimations  contains  some  kind  of  inaccuracy  and  will  need  to  be  reworked.  If  the 
numbers  correlate  well,  one  could  assume  some  statistical  validity  between  the  two 
different  estimates  obtained  from  different  sources. 
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The  data  collection  to  perform  the  initial  analysis  can  be  concluded  upon 
gathering  the  number  of  command  units  involved  in  the  overall  process  (in  this  case,  it  is 
the  number  of  command  units  involved  in  performing  account  management);  the  number 
of  people  involved  in  each  sub-process  per  command  unit;  an  accurate  count  of  the 
number  of  times  the  knowledge  is  executed  during  a  sampling  period  (in  this  case,  one 
week);  and  the  time  it  takes  to  execute  each  core  process  (called  Time  to  Complete).  To 
assist  in  ensuring  that  the  knowledge  estimates  are  accurate,  it  is  important  to  avoid 
overestimation  —knowledge  should  only  be  counted  when  in  use,  that  is,  when  it  is  being 
actively  utilized  to  perfonn  a  particular  sub-process  or  process. 

2.  KVA  Calculations 
a.  Assumptions 

•  Except  where  noted,  all  command  units  utilize  the  same  overall  process 
and  sub-processes  for  account  management. 

•  The  number  of  persons  completing  each  sub-process  is  an  average  taken 
from  actual  survey  data. 

•  Times  Fired  is  an  average  number  of  times  that  each  sub-process  was 
completed  by  a  single  technical  representative  in  the  sample  period  of  a 
week.  This  average  was  then  converted  to  number  of  times  fired  in  an  hour 
for  purposes  of  comparability.  The  data  used  to  derive  this  average  came 
from  the  surveys. 

•  Time  to  Complete  is  the  average  time  it  took  a  single  technical 
representative  to  complete  one  instance  of  the  sub-process.  This  average 
was  derived  from  survey  data. 

To  calculate  the  “benefit”  stream  for  each  sub-process,  the  ALT  (hours) 
was  multiplied  by  the  Times  Fired/hour  times  the  Average  #  People  completing  the  sub 
process.  This  provided  the  number  of  units  of  knowledge  generated  by  a  single  command 
unit  for  the  sub-process  for  the  sample  period.  This  was  then  multiplied  by  the  total 
number  of  command  units  to  obtain  the  total  units  of  knowledge  generated  by  all 
commands  for  this  sub-process.  Figure  15  provides  a  partial  illustration  of  the  use  of  this 
formula  in  the  NMCI  process.  (J=  C  x  D  x  F  x  H) 
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Figure  15.  KVA  Total  Benefits  Calculation  Example. 


For  the  purposes  of  this  particular  analysis,  a  surrogate  was  used  for  actual 
unit  cost  due  to  the  difficulty  of  obtaining  actual  cost  data  for  so  many  moving  parts 
within  the  allotted  time  frame.  To  estimate  this  surrogate  for  unit  cost,  it  was  agreed  that 
the  number  of  hours  that  it  took  to  complete  a  sub-process  (Time  to  Complete)  was  a 
reasonable  equivalent  to  the  actual  dollar  unit  cost  since  dollar  unit  cost  is  the  wages/hour 
paid  to  complete  the  sub-process.  Once  a  unit  cost  surrogate  was  selected,  this  was 
multiplied  by  the  Times  Fired/hour  times  the  Average  #  People  completing  the  sub 
process  and  finally  by  the  total  number  of  command  units  to  obtain  the  total  “cost”  of  the 
knowledge  generated  by  all  commands  for  this  sub-process.  Figure  16  provides  a  partial 
illustration  of  the  use  of  this  formula  in  the  NMCI  process.  (K=  C  x  D  x  F  x  G) 
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Figure  16.  KVA  Total  Costs  Calculation  Example. 


3.  Metrics 

In  order  to  glean  meaningful  insights  from  the  KVA  analysis,  it  was  necessary  to 
build  a  performance  ratio  for  the  sub-processes.  For  this  ratio,  ROK  was  used.  The  ROK 
calculation  used  the  standard  formula: 


ROK  =  — 
C 


where: 


K  =  Knowledge  generated  by  a  single  core  process 

C  =  Cost  assigned  to  Time  to  Complete  a  single  core  process,  or  surrogate  for  cost 
assigned 

The  actual  calculation  for  “Create  Add  User  to  User  Log”  is  as  follows: 

ROK  =  -3^45- . 

.8625 

This  ROK  is  400%,  meaning  that  there  are  four  units  of  knowledge  generated  for 
every  unit  of  knowledge  “cost.”  In  other  words,  for  every  hour  that  it  takes  to  complete 
this  sub-process,  it  requires  four  hours  of  Learning  Time. 

Once  the  ROK  ratios  for  all  sub-processes  were  completed,  it  was  determined  that 
they  were  too  inflated  to  provide  helpful  insights.  Thus,  the  decision  was  made  to  lower 
these  ratios  by  a  divisor  of  25  throughout,  so  that  more  meaningful  comparisons  could  be 
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made.  Using  a  common  devisor  assists  with  getting  the  percentages  to  fall  between  1% 
and  100%.  Decimal  numbers  that  fall  below  1%  and  any  ratios  greater  than  100%  can 
easily  be  assessed  as  they  standout  from  the  predetennined  percentage  range.  If  every 
number  in  a  series  is  divided  by  the  same  divisor,  the  proportional  relationships  between 
those  numbers  remain  intact. 

4.  Analysis  of  Results 

To  provide  an  in-depth  analysis  of  the  results,  some  ranges  of  perfonnance  for  the 
ROK  ratios  were  established.  All  sub-processes  below  10%  ROK  were  the  first  line  of 
investigation  for  process  reengineering.  All  sub-processes  between  10%  and  20%  ROK 
were  the  second  area  of  investigation.  Once  Categories  1  and  2  were  reviewed,  the  focus 
fell  on  Category  3  (ROK  over  20%)  to  see  whether  it  was  possible  to  build  more 
efficiency  or  effectiveness  here  as  well. 

Category  1  -  ROKs  of  less  than  10%:  the  amount  of  automation  vs.  the  amount  of 
manual  labor  involved  was  examined.  Then,  the  amounts  of  “wait  time”  built  into  the 
sub-processes  were  reviewed,  e.g.,  did  a  sub-process  require  the  CTR  to  wait  prolonged 
periods  to  receive  a  response.  Also  investigated  were  the  IT  systems  used  to  see  if 
streamlining  was  needed  and  whether  too  many  systems  were  required  to  accomplish  a 
given  task.  It  was  clear  that  the  sub-processes  yielding  a  less  than  10%  ROK  were  heavily 
manual,  included  long  “wait  times,”  and  required  multiple  inputs  into  various  IT  systems. 

Category  2  -  ROKs  between  10%  and  20%:  the  same  methodology  as  that  for 
Category  1  was  followed.  Note  that  in  this  Category,  many  of  the  sub-processes  were 
locked  in  place  due  to  business  rules  that  required  them  to  remain  in  effect.  An  example 
of  this  was  Sub-Process  5  -  REDCOM  Approval.  All  four  Category  2  sub-processes, 
with  the  exception  of  the  REDCOM  Approval,  were  manual  sub-processes  and  could  be 
automated  without  losing  valuable  data. 

It  was  also  discovered  that  both  Category  1  and  Category  2  sub-processes 
included  many  redundancies  that  could  be  consolidated  or  eliminated  by  better  process 
design. 

Category  3  -  ROKs  over  20%:  Although  the  returns  were  high  by  comparison 
with  the  other  sub-processes,  it  was  noted  that  the  technical  representatives  were  required 
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to  utilize  several  IT  systems  to  accomplish  otherwise  automated  tasks.  This  meant  that 
time  was  consumed  on  switching  systems  that  could  have  been  used  in  producing 
outputs. 

Globally,  the  ROK  analysis  made  it  possible  to  understand  that  there  was  no  fully 
integrated  central  data  repository  that  an  “actor”  or  technical  representative  could  actually 
use  to  accomplish  account  management.  In  addition,  it  was  found  that  not  ah  technical 
representative  had  been  trained  to  use  ah  the  systems  they  were  expected  to  utilize  and 
often  technical  representative  were  not  even  using  these  systems  at  ah,  whether  trained 
for  them  or  not.  It  was  evident  from  ah  these  investigations  and  the  ROK  analysis  that 
serious  reengineering  of  the  account  management  sub-processes  was  needed. 

Figure  17  shows  the  complete  KVA  analysis. 
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The  current  use  of  IT  was  factored  into  the  learning  of  each  of  the  sub-processes 
as  most  of  these  sub-processes  are  perfonned  by  entering  data  into  a  myriad  of  electronic 
IT  systems  or  applications.  In  analyzing  the  As-Is  process,  it  was  concluded  that  the  issue 
was  not  the  lack  of  IT,  but  rather  the  lack  of  integration  between  all  the  different 
electronic  systems  and  applications  used  to  manage  accounts.  The  systems  included  the 
NMCI  Enterprise  Account  Management  Tool  (NET)  to  manage  seats  but  contained 
limited  functionality  to  manage  accounts;  eMarketplace  to  validate  the  monthly  billing 
invoices;  Service  Request  Electronic  Form  (SR  eForm)  for  daily  MAC  submissions  and 
management;  MS  Outlook  for  confirmation  of  MAC  submissions  and  completions;  the 
Global  Address  List  (GAL)  to  verify  the  establishment  or  disestablishment  of  accounts; 
and  a  multitude  of  local  applications  (i.e.,  locally  generated  MS  Excel  spreadsheets  and 
MS  Access  databases)  assist  in  storing  all  the  data  gathered  from  the  various  systems  in 
one  location.  Active  Directory  is  used  very  little  when  perfonning  the  required  monthly 
validation  of  invoices. 

It  is  also  important  to  note  that  not  all  processes  are  electronic.  Many  of  the 
technical  representatives  have  created  manual  logbooks  in  an  effort  to  manage  the  status 
of  MACs  from  creation  to  completion.  Also  noteworthy  is  that  the  SR  eForm  was  not 
fully  functional  for  MAC  management  at  the  beginning  of  this  analysis.  Instead,  the 
ACTRs  submitted  all  requests  requiring  the  contractor’s  intervention  via  email  to  the 
DCTR,  and  the  DCTR  in  turn,  forwarded  them  to  the  SRM  team.  The  ACTR’s  inability 
to  demonstrate  proficiency  in  using  the  SR  eForm  during  the  site  visit  was  evidence  that 
it  was  not  used  to  manage  all  MACs,  and  more  importantly,  that  the  users  received  little 
or  no  training  on  its  functional  attributes. 

The  results  of  the  As-Is  analysis  made  it  possible  to  develop  a  proposed  To-Be 

solution  for  each  of  the  four  scenarios  previously  mentioned.  The  “To-Be”  process  flow 

and  KVA  were  detennined  and  developed  by  building  a  demonstrable  web-based 

prototype.  This  prototype  website  integrated  the  functionality  and  processes  included  in 

the  myriad  of  IT  systems  previously  mentioned.  The  website  also  includes  easily 

accessible  on-line  help  and  training  information  to  the  technical  representatives.  Figures 

18-21  illustrates  the  recommendations  for  near-term  changes  in  the  current  system  and 

account  management  business  processes.  Each  of  these  corresponds  to  their  counterpart 
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scenario  in  the  As-Is  process.  As  noted  by  the  red  outline  or  the  strike  through  the  middle 
of  the  process  or  application,  several  of  the  current  sub-processes  will  be  changed  or 
deleted  because  of  the  proposed  solution.  Appendix  C  provides  more  information  about 
the  prototype  website  and  the  functionality  included. 

H.  “TO-BE”  PROCESS  FLOWCHARTS 

The  following  figures  illustrated  the  “To-Be”  version  of  the  account  management 
process  flows.  The  focus  will  be  less  on  each  individual  step,  since  they  were  explained 
in  the  As-Is,  and  more  on  the  changes  that  have  occurred  in  the  process  scenarios.  Note 
that  perforated  lines  that  existed  around  many  of  the  As-Is  steps  are  now  eliminated  to 
demonstrate  mandatory  completion  and  consistency  throughout  the  USN  RC. 

1.  Scenario  1 
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Figure  18.  To-Be  Flowchart  When  a  New  DRILLRES/FTS  Reports  for  Duty. 
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The  first  scenario  shows  the  changes  in  the  process  flow  for  DRILLRES  or  FTS 
personnel  who  are  either  new  to  the  USN  RC  or  who  are  transferring  from  a  non-NMCI 
command.  The  changes  in  the  process  are  as  follows. 

•  The  logbook  entry  made  by  the  NMCI  account  manager  when  the  User  in¬ 
processes  is  no  longer  manual  but  is  now  entered  into  an  electronic  web- 
based  solution.  The  User  enters  all  information  while  still  physically 
working  with  the  technical  representative.  Researchers  of  data  quality 
have  conducted  tests  to  statistically  prove  that  data-entry  errors  will  be 
minimized  if  data  is  entered  by  its  owner.  This  entry  begins  the  account 
verification  process.  If  other  account  names  exist  in  the  central  data 
repository  that  match  the  User,  the  technical  representative  will  receive 
immediate  results  of  any  name  match  and  can  clarify  the  account  status 
while  the  user  is  physically  present.  The  functionality  will  eliminate  the 
time  lapse  built  into  the  As-Is  scenario. 

•  The  integrated  website  eliminates  the  requirement  to  send  the  MAC 
request  to  the  authorized  submitter  to  review  for  accuracy  and 
completeness.  Entering  of  required  data  by  the  User,  and  the 
incorporation  of  form  field  validation  in  the  website  design  will  ensure 
that  the  infonnation  is  complete  but  does  not  eliminate  the  need  for  the 
authorized  submitter  to  review  the  request  for  accuracy.  Once  the  MAC 
request  has  been  submitted  by  the  authorized  initiator  in  the  integrated 
web-based  system,  the  request  will  automatically  appear  in  the  in-box  of 
the  authorized  submitter.  The  authorized  submitter  can  then  verify  for 
accuracy  and  submit  the  request  directly  to  the  contractor’s  Service 
Request  Management  (SRM)  Team  for  further  action. 

•  To  achieve  efficiency  in  time  and  to  achieve  the  maximum  use  of  the  two 
“free”  accounts  that  accompany  each  seat,  the  integrated  web-based 
solution  records  every  seat  occupied  and  unoccupied  with  the  two 
accounts.  Any  accounts  added  are  automatically  assigned  the  first 
available  seat.  Any  accounts  no  longer  in  use  are  automatically 
unassigned  to  that  seat,  and  subsequently,  account  history  is  automatically 
stored  in  the  database.  This  history  allows  for  the  instant  retrieval  of 
account  User  data  when  a  new  account  name  matches  any  that  exists  in  the 
history  file  or  table.  This  eliminates  the  creation  of  duplicate  accounts  and 
would  only  require  re-activation  of  an  account  that  may  have  been  placed 
in  an  inactive  status. 
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2. 


Scenario  2 


Figure  19.  To-Be  Flowchart  When  an  FTS/DRILLRES  Transfers. 


The  second  scenario  shows  the  changes  in  the  process  flow  for  DRILLRES  or 
FTS  personnel  that  relocate  from  one  command  on  the  NMCI  network  to  another 
command  on  NMCI.  The  changes  in  the  process  are  as  follows. 

•  Just  as  in  Scenario  1,  the  logbook  entry  made  by  the  NMCI  account 
manager  when  the  User  in-processes  is  no  longer  manual  but  is  now 
entered  into  an  electronic  web-based  solution. 

•  The  technical  representative  can  then  automatically  unassign  the  User 
from  the  occupied  seat  by  initiating  an  account  transfer  from  the  losing 
command  to  the  gaining  command.  Initiation  of  an  account  transfer  by  the 
local  technical  representative  will  automatically  submit  an  account  transfer 
request  to  the  in-box  of  the  gaining  technical  representative.  Automating 
this  process  eliminates  the  need  to  inform  the  gaining  technical 
representative  that  an  account  transfer  is  required.  Submitting  the  request 
does  not  eliminate  fiscal  and  management  responsibility  by  the  local 
technical  representative  until  the  account  has  been  accepted  by  the  gaining 
command  via  the  integrated  web-base  tool. 

•  Management  oversight  by  the  technical  representative  is  still  required  to 
ensure  that  the  account  is  removed  from  the  local  Active  Directory.  This 
requirement  does  not  eliminate  the  account  transfer  verification  loop  that 
is  included  in  the  As-Is,  but  it  does  eradicate  the  requirement  to  submit  the 
MAC  request  via  email  to  the  authorized  submitter. 
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3. 


Scenario  3 


Figure  20.  To-Be  Flowchart  When  an  FTS/DRILLRES  Transfers. 


Scenario  three  illustrates  the  changes  in  the  process  flow  for  DRILLRES  or  FTS 
personnel  retiring,  leaving  the  military  service,  or  transferring  to  a  non-NMCI  command. 
The  changes  in  the  process  are  as  follows. 


•  The  integrated  web-based  data  repository  eliminates  the  need  for  the 
technical  representative  to  complete  the  MS  Word  document  and  submit 
the  MAC  request  to  the  authorized  submitter  via  email.  Once  the  request 
is  entered  in  the  web-based  tool,  it  is  automatically  sent  to  the  authorized 
submitter  and  awaits  action  in  the  in-box. 


4. 


Scenario  4 
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Figure  2 1 .  To-Be  Flowchart  for  Allocation  of  Accounts  and  Seat  Management. 


Scenario  four  illustrates  the  changes  in  the  process  flow  for  overall  management 
of  NMCI  seats  and  accounts.  The  scenario  illustrates  that  most  of  the  sub-processes 
included  in  the  As-Is  are  now  modified  to  include  the  use  of  the  web-based  integrated 
central  data  repository  with  NET  and  eMarketplace.  Again,  the  top  process  flow  is  for 
accounts  and  the  bottom  is  for  seats.  The  changes  in  the  processes  are  as  follows. 
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a.  Accounts 

•  Initially,  the  technical  representative  would  ensure  that  all  current  NMCI 
users  are  entered  into  the  integrated  web-based  management  tool.  By 
using  automated  reports  that  could  be  generated  and  exported  from  the 
web-based  tool,  the  technical  representative  would  perform  a  comparison 
between  the  active  accounts  in  the  Active  Directory  and  the  system 
generated  report.  Any  disparities  or  MAC  requirements  would  be 
submitted  directly  through  the  integrated  web-based  tool.  There  would 
not  be  a  need  to  compare  the  Active  Directory  numbers  manually  to  the 
“free”  seats  to  determine  CLIN  0024s  as  the  account-to-seat  allocation 
would  be  system  generated.  Likewise,  the  system  would  automatically 
calculate  any  account  requirements  that  exceeded  the  “free”  accounts  that 
accompanied  each  seat  by  providing  a  sum  total  of  required  CLIN  0024s. 

•  The  web-based  tool  is  sophisticated  enough  to  generate  a  report  that 
contains  accumulated  seat  and  account  data  with  similar  data  output  fields 
that  exist  in  eMarketplace.  This  would  enable  the  technical  representative 
to  generate  a  report  through  the  web-based  tool  and  compare  it  with  the 
eMarketplace  invoice. 

b.  Seats 

•  Ensuring  that  actual  seat  data  match  what  exists  in  NET  since  NET  is 
currently  the  management  tool  of  choice.  The  integrated  web-based  tool 
allows  technical  representatives  to  perfonn  a  physical  inventory  of  their 
existing  assets,  enter  the  findings  in  the  web-based  tool,  and  provide  an 
interface  with  the  NET  seat  module  to  provide  easy  and  automated  import 
of  data  between  the  systems.  The  interface  between  the  prototype  web- 
based  tool  and  NET  would  eliminate  the  requirement  to  submit  any 
modifications  via  a  spreadsheet  to  the  authorized  submitter. 

5.  Data  Analysis  Comparison 

The  principles  of  KVA  and  BPR  were  used  to  recommend  modifications  and  to 
achieve  efficiencies  in  the  account  management  process.  It  was  decided  that  addressing 
the  ROKs  that  met  the  criteria  for  Category  1  above  would  provide  the  most  immediate 
return  as  manual  processes  would  be  automated  thus  decreasing  the  time  to  complete  the 
sub-process.  Additionally,  the  desire  was  to  capture  as  much  knowledge  in  the  heads  of 
people  and  embed  it  in  the  IT  system  when  feasible.  The  numbers  included  for  the  “To- 
Be”  Time  to  Complete  and  the  Actual  Learning  Time  are  based  on  the  testing  and 
evaluation  of  the  prototype  web-based  solution,  and  not  just  professional  judgment. 

While  adding  automation  did  eliminate  most  manual  processes,  it  also  required 
additional  sub-processes  to  compensate  for  the  automation.  The  KVA  shows  an  increase 
in  the  ROK  in  several  of  the  sub-processes.  The  ROK  increase  is  attributable  to  an 
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increase  in  knowledge  embedded  in  the  IT  systems,  as  smarter  IT  systems  require  less 
knowledge  of  the  process  in  the  minds  of  the  account  management  actors,  to  the  merging 
of  several  processes  into  one,  the  elimination  of  manual  sub-processes,  and  a  decrease  in 
the  time  to  complete  each  of  the  remaining  sub-processes.  The  following  sub-processes 
were  eliminated  with  the  use  of  automation  and  system  integration:  Fill  out  Request 
Document  (MAC)  in  Word  (sub-process  row  #5)  and  Aggregate  CLIN  spreadsheet  sent 
to  NET  website  (sub-process  row  #19).  These  sub-process  rows  are  highlighted  in  grey 
in  Figure  22.  As  previously  mentioned,  the  following  sub-processes  were  required  to  be 
added  because  of  automation  and  system  integration:  Fill  out  Electronic  Log  Request 
(sub-process  row  #4);  Verity  Unit  Information  and  submit  rapid  request  (sub-process  row 
#8);  and  Track  Equipment  Purchases  through  the  new  web-based  site  (sub-process  row 
#18).  These  sub-processes  have  a  red  font  color  and  have  a  grey  highlight  in  the  “Before 
(from  As-Is)”  column  (column  L). 

The  remaining  sub-processes  with  red  font  color  within  the  numbers  represent 
those  that  have  been  modified  with  the  use  of  an  integrated  and  automated  central  data 
repository.  While  many  interpretations  can  be  made  from  the  data,  the  data  analysis  for 
this  section  focuses  only  on  the  increases  or  decreases  to  the  Time  to  Complete,  which 
affects  increases  or  decreases  to  the  proxy  “cost”  discussed  in  Section  C  of  this  chapter. 
In  other  words,  the  analysis  focuses  on  how  the  process  changes  improved  the  benefit 
stream  and/or  the  decreased  the  proxy  costs.  This  is  done  by  comparing  the  Time  to 
Complete  from  the  “To-Be”  to  the  Time  to  Complete  from  the  “As-Is”.  These  processes 
include  the  following. 

•  Review  User  Log  and  Check  for  existing  account  (sub-process  row  #6). 
Since  this  sub-process  will  be  automatically  performed  through  the 
integrated  website,  through  testing  and  evaluation,  it  was  determined  that 
automation  would  yield  a  decrease  in  the  Time  to  Complete  from  0.05 
hours  to  0.03  hours.  The  analysis  of  the  data  concluded  that  the 
percentage  of  time  to  complete  was  decreased  by  40%. 

(0.03-0.05)  Q/| 

0.05 

Similar  comparisons  will  be  made  with  the  remaining  processes  that  have  been 
changed. 
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Ask  User  about  need  for  multiple  accounts  (sub-process  row  #7).  This 
sub-process  will  no  longer  allow  the  technical  representative  to  wait  until 
after  a  drill  weekend  to  contact  a  NMCI  user,  but  will  enable  him  to  ask 
the  user  at  the  time  the  new  NMCI  account  is  requested.  Using  the  same 
comparison  methodology  as  the  previous  sub-process,  it  can  be  concluded 

(0.03-0.5) 


that  the  Time  to  Complete  was  decreased  by  94%. 


0.5 


=  -.94 


Assign/Unassigned  User  to  seat  in  our  Site  (sub-process  row  #12).  This 
sub-process  eliminates  the  need  for  the  technical  representative  to  perform 
unused  seat-to-account  mapping  in  their  local  tracking  system  (from  As-Is, 
Figure  17,  sub-process  row  #10).  The  use  of  automation  and  system 
integration  automatically  finds  the  first  available  or  unused  seat  and 
performs  user-to-seat  mapping  as  they  are  entered.  Data  analysis  yields  a 

75.7%  decrease  in  the  Time  to  Complete.  ^ =  -0.757 

0.33 


Contact  User’s  Prospective  Command  (sub-process  row  #15).  Great 
efficiency  is  achieved  in  this  area  by  using  the  prototype  tool  as  the 
process  of  transferring  and  the  account  is  mostly  system  generated.  This 
increases  the  number  of  times  this  process  can  be  completed  in  an  hour 
and  decreases  the  overall  time  to  complete  one  instance  of  the  sub-process. 
Analysis  of  the  data  concludes  a  94.4%  decrease  in  the  completion  time. 
(0.083-1.5) 


1.5 


=  -.944 


•  Look  up  Invoice  Page  on  eMarketplace  (sub-process  row  #16).  Since  all 
of  the  data  will  be  integrated  into  the  web-based  tool,  the  technical 
representative  is  required  only  to  generate  a  report  and  complete  the 
verification.  Automating  this  process  drastically  decreases  the  Time  to 

Complete  by  83.3%.  — ^  —  =  -.833 

KVA  provides  the  data  analysis  with  many  options  for  data  comparison  within  the 
sub-processes  or  with  overall  ROK  percentages.  The  numbers  in  the  spreadsheets  listed 
previously  represents  a  relative  comparison  between  the  ROK  for  the  As-Is  and  the  To- 
Be  processes.  A  relative  comparison  between  the  overall  ROK  totals  yield  a  6.95% 
increase  in  overall  efficiency  (31.70%  -  24.75%=6.95%). 
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Figure  22.  KVA  To-Be  Analysis. 


I.  CHAPTER  SUMMARY 

This  chapter  began  by  providing  detailed  information  on  the  theory  of  Knowledge 
Management.  The  definition  of  Knowledge  Management  was  provided  and  can  be 
summarized  as  a  set  of  activities  aided  by  IT  designed  to  help  organizations  to  create, 
capture,  synthesize,  deploy,  share,  preserve,  and  reuse  organizational  knowledge  more 
effectively.  The  section  on  BPR  addressed  its  phases  as  defined  by  El  Sawy.  The 
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evolution  of  Knowledge  Management  has  constituted  what  is  considered  the  “second- 
wave”  BPR,  which  focuses  on  effectively  managing  knowledge  around  business 
processes.  The  chapter  demonstrated  how  the  process  redesign  heuristics  and  the  KVA 
methodology  was  used  to  increase  the  knowledge-creating  capacity  of  the  account 
management  process  so  that  it  learns  more  effectively  through  the  interactions  of  its 
various  participants. 

KVA  methodology  was  also  used  to  measure  the  ROK  as  a  way  of  comparing 
how  much  value  different  BPR  alternatives  provide  to  the  account  management  process. 
BPR  emphasizes  the  importance  of  creating  value  quickly  and  value  can  be  created 
through  increased  knowledge  creation  around  processes.  Developing  a  web-based 
prototype  enabled  the  testing  and  evaluation  of  BPR  alternatives  and  was  used  to 
calculate  the  To-Be  process  flow  for  the  various  defined  scenarios.  The  KVA 
methodology  uniquely  enabled  the  ability  to  capture  and  quantitatively  measure  the 
amount  of  knowledge  as  a  common  unit  of  output  that  exists  in  each  of  the  sub-processes 
in  managing  NMCI  accounts.  This  could  not  have  been  accomplished  solely  with  the  use 
of  BPR  principles.  Quantitatively  capturing  the  knowledge,  in  units  of  learning  time, 
allowed  relative  comparisons  of  the  sub-processes  and  the  ROK  to  be  made. 

The  next  chapter  provides  an  analysis  of  what  industry  considers  successful 
measures  for  outsourcing  and  seat  management.  It  also  examines  commercial  companies 
that  have  outsourced  their  IT  resources  and  the  business  practices  implemented  that  led  to 
their  success.  The  second  half  of  the  chapter  reviews  best-of-breed  COTs  tools  used  by 
industry  to  perform  enterprise-wide  seat  management. 
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V.  INDUSTRY  STANDARDS  FOR  OUTSOURCING  AND 
COMMERCIAL-OFF-THE-  SHELF  MANAGEMENT  TOOLS 

A.  INTRODUCTION 

Researchers  have  documented  that  information  technology  (IT)  outsourcing  has 
increased  enormously  over  the  past  decade.  This  increase  has  required  that  outsourcing 
organizations  create  and  codify  standards  and  best  practices  that  promote  sharing 
strategies  and  ensure  tangible,  sustainable  results.  This  chapter  discusses  some  of  these 
strategies  based  on  research  conducted  by  Gartner  Inc.  and  other  outsourcing  researchers. 
Included  in  the  chapter  are  industry  best  practices  for  administering  and  managing 
information  technology  (IT)  outsourcing  contracts. 

Previous  chapters  discussed  the  lack  of  an  integrated  IT  solution  and  its  impact  on 
Navy  Marine  Corps  Intranet  (NMCI)  management.  This  chapter  assesses  “best-of- 
breed”  commercial-off-the-shelf  (COTS)  products  used  by  industry,  which  could  also  be 
used  as  an  enterprise  IT  solution  for  NMCI  management. 

B.  INFORMATION  TECHNOLOGY  OUTSOURCING  BEST  PRACTICES 

Many  enterprises,  or  service  recipients  (SR),  have  decided  to  outsource  all,  or  a 
portion  of  their  IT  functions  to  increase  value  and  add  benefits  to  the  organization. 
William  Maurer  of  Gartner  Research  states  that  some  of  these  benefits  are  that  the 
organization  is  allowed  to  concentrate  on  core  competencies;  speed  to  market  is 
enhanced;  change  management  initiatives  are  improved;  and  costs  are  lowered  [Ref.  24]. 
While  IT  outsourcing  has  gained  tremendous  popularity  in  today’s  business  environment, 
more  than  half  of  all  outsourcing  arrangements  fail  to  deliver  the  expected  benefits  or 
value  [Ref.  25],  This  failure  has  been  attributed  to  mismanagement  of  outsourcing 
endeavors  from  the  establishment  of  the  sourcing  plan  to  the  management  of  the  contract 
after  it  is  awarded.  The  following  sub-section  discusses  the  widely-accepted  four  phases 
of  strategic  outsourcing.  While  there  are  many  forms  of  outsourcing  deals,  a  phased- 
approach,  focused  on  IT  utility  sourcing  contracts,  will  be  discussed  since  it  is  relevant  to 
the  NMCI  environment. 
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1.  Four  Phases  of  Strategic  Outsourcing 

Gartner  Research  has  studied  the  behaviors  and  practices  of  outsourcing  strategies 
as  well  as  its  methodologies.  They  have  recognized  that  most  organizations  lack  the 
skills  required  to  manage  the  outsourcing  relationship  with  external  service  providers 
(ESPs)  once  it  has  been  established  [Ref.  26].  To  assist  with  the  process,  Gartner  states 
that  decision-makers  need  to  carefully  craft  their  strategic  outsourcing  plans  to  allow  for 
“partnerships”  with  their  ESPs.  These  partnerships  will  enable  businesses  to  become 
more  agile  with  their  customers  and  the  changing  requirements  of  the  organization  [Ref. 
26].  Establishing  a  partnership  is  not  something  that  occurs  suddenly,  but  should  be 
revealed  by  using  an  evolutionary  approach,  which  Gartner  refers  to  as  the  four  phases  of 
strategic  outsourcing  process.  The  phases  of  the  strategic  outsourcing  process  shown  in 
pictorial  form  in  Figure  23  are: 

•  Sourcing  Strategy 

•  Evaluation  and  Selection 

•  Contract  Development 

•  Sourcing  Management 

This  process  has  become  the  industry  standard  for  outsourcing  as  it  takes 
enterprises  from  the  initial  decision,  to  strategic  outsourcing,  and  through  ongoing 
management  of  the  partnership  during  the  life  of  the  contract.  The  process  considers 
future  objectives,  new  opportunities,  and  the  potential  for  change  [Ref.  26]. 


Figure  23. 
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Strategic  Sourcing  Process  (From:  Ref.  26). 


a.  Phase  1:  Sourcing  Strategy 

Phase  1  begins  with  the  questions  of  business  strategy  and  goals. 
Knowing  the  goals  and  direction  of  the  organization  enables  senior  leadership  to 
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determine  which  services  would  be  handled  most  effectively  through  outsourcing. 
Jennifer  Beck,  Gartner  Research  analyst,  states  that  most  organizational  leadership  agree 
that  one  of  the  biggest  challenges  in  outsourcing  is  aligning  IT  with  the  business  strategy 
[Ref  27]. 

During  this  phase,  organizations  should  carefully  define  and  closely 
analyze  their  enterprise  and  evaluate  the  risks  and  benefits  of  outsourcing.  They  should 
clearly  understand  what  is  required  in  the  final  contract  at  award  and  consider  what  is 
preferred  throughout  its  duration.  Selection  of  vendors  should  be  cautiously  made  as  any 
outsourcing  partnership  formed  solely  on  present  circumstances  is  not  thinking 
strategically  and  could  be  doomed  for  failure.  Vendors  should  also  be  selected  based  on 
their  ability  to  meet  the  strategic  goals  of  the  organization.  This  will  establish  a  context 
for  well-timed  future  success. 


Figure  24.  Phase  1:  Sourcing  Strategy  (From:  Ref.  26). 

b.  Phase  2:  Evaluation  and  Selection 

Phase  2  empowers  senior  leadership  to  define  its  requirements  and  identify 
potential  partners  that  can  meet  the  organization’s  business  needs.  Organizations  should 
evaluate  potential  service  providers  by  establishing  guidelines  regarding  contract 
flexibility  and  cooperative  decision-making  that  will  govern  the  final  contract.  A 
decision  framework  for  evaluating  and  selecting  vendors  is  also  included  in  this  phase  of 
the  strategic  sourcing  life  cycle. 

There  are  several  ways  that  vendors  can  be  selected  but  two  of  the  more 
popular  means  is  through  Request  for  Proposal  (RFP)  and  Single-Source. 

Gartner  Research  states  that  soliciting  vendor  interest  by  using  the  RFP 
approach  “invites  about  five  to  twelve  service  providers  to  respond  to  the  requirements 
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stated  RFP.  It  then  attempts  to  uncover  key  differences  among  the  service  providers” 
[Gartner  Research  in  Ref.  26].  The  negative  aspect  of  this  approach  is  that  service 
providers  submit  boilerplate  responses  as  a  result  of  cost-of-sale  and  opportunity-to-win 
concerns  among  the  many  respondents.  The  RFP  approach  usually  requires  the  longest 
timeframe  and  more  is  expensive  than  the  Single  Source  approach. 

The  Single  Source  approach  invites  one  service  provider  to  develop  an 
offer.  Selecting  a  vendor  using  this  approach  is  usually  driven  by  an  existing  relationship 
the  vendor  may  have  with  the  organization.  In  government  organizations,  the  single 
source  approach  must  be  accompanied  with  justification.  It  is  often  used  when  there  is  a 
need  for  unique  skills,  tools,  or  technology.  Services  that  are  limited  by  time  constraints 
also  warrant  the  use  of  the  single  source  approach.  Although  this  approach  may  seem  to 
shorten  the  negotiation  process,  it  can  also  lengthen  it  or  establish  an  inequitable 
agreement  when  the  service  provider  desires  certain  contract  terms  and  when  the  service 
recipient  is  anxious  to  close  a  deal  [Ref.  26].  In  addition,  the  lack  of  competition  among 
service  providers  can  also  remove  incentives  for  the  selected  provider  to  offer  the 
purchasing  organization  the  best  terms  and  services. 

Realistic  expectations  about  costs  and  service  benefits  should  also  be 
realized  during  this  phase.  Gartner  believes  that  only  when  a  decision  is  made  on  these 
elements  can  the  search  for  a  service  provider  proceed  successfully  and  efficiently. 


Figure  25.  Phase  2:  Evaluation  and  Selection  (From:  Ref.  26). 
c.  Phase  3:  Contact  Development 

Phase  3  assists  users  in  constructing  the  proper  contract  based  on  their 
needs  and  negotiating  the  appropriate  deals  with  the  vendor.  In  this  phase,  the  SR  and 
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service  provider  (SP)  structure  a  flexible  partnership  with  defined  service  levels  and 
payment  models  by  negotiating  a  realistic  and  effective  contract.  “Hammering  out  the 
details  of  performance  measures  and  terms  that  are  flexible  enough  to  withstand  changes 
during  the  course  of  the  partnership  is  crucial”  [Ref.  26].  Many  IT  outsourcing  contracts 
were  awarded  based  on  misunderstandings  about  cost.  The  initial  costs  may  look 
appealing  because  surcharges  are  buried  in  the  details  for  later  years  and  the  cost  of 
managing  the  partnership  over  time  is  rarely  taken  into  consideration. 

Performance  measures  must  be  made  clear  and  a  realistic  assessment  of 
the  true  costs  in  the  contract  must  be  made.  Equally  important,  the  contract  terms  should 
be  flexible  enough  to  withstand  the  inevitable  changes  that  take  place  during  the  course 
of  a  partnership. 


Figure  26.  Phase  3:  Contact  Development  (From:  Ref.  26). 
d.  Phase  4:  Outsourcing  Management 

The  fourth  phase  involves  project  management  once  the  contract  has  been 
awarded.  Since  the  outsourcing  process  does  not  end  after  the  contract  is  signed,  the 
partnership  between  the  SR  and  SP  must  be  maintained  as  a  living,  breathing  entity.  It 
must  be  monitored  and  nurtured  to  ensure  that  the  conditions  of  the  contract  are  met  and 
modified  as  the  business  requirements  change.  As  shifts  in  capacities,  needs  and 
opportunities  to  innovate  occur,  the  partnership  should  use  benchmarking  to  make  sure  it 
is  aware  that  change  is  taking  place.  To  foster  a  healthy  working  relationship,  both 
parties  must  consider  these  changes  when  reassessing  the  terms  of  the  contract.  Gartner 
believes  that  this  is  the  only  way  to  keep  the  partnership  fresh  and  alive. 
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Figure  27.  Phase  4:  Sourcing  Management  (From:  Ref.  26). 

There  are  many  ways  to  determine  whether  the  SP  is  providing  an 
organization  the  service  it  desires  and  meeting  its  expectations  in  a  sourcing  contract. 
Industry  has  defined  some  of  these  as  qualitative  determinants  and  some  can  be  measured 
quantitatively.  The  focus  of  the  research  in  the  following  sub-sections  includes  two  well- 
known  quantitative  approaches  to  measuring  contract  performance,  benchmarking  and 
service-level  agreements.  It  is  believed  that  these  two  approaches  provide  the  most  value 
to  an  enterprise. 

2.  Benchmarking 

Today’s  business  requirements  dictate  that  organizations  be  flexible  and  possess 
an  ability  to  change  at  a  moment’s  notice  and  that  change  must  be  institutionalized 
quickly  and  effectively.  Benchmarking  is  one  of  a  number  of  quantitative  approaches  to 
ensure  that  an  organization  and  the  SP  are  maintaining  the  agreed  upon  levels  of 
organizational  change  and  are  prepared  for  possible  reevaluation  of  contractual  courses  of 
action. 

When  defining  the  requirements  of  the  IT  resources  to  be  obtained  through 
outsourcing,  it  is  not  practical  to  set  absolute  standards  for  performance  in  an 
environment  of  continual  change.  A  common  alternative  is  benchmarking. 
Benchmarking  is  defined  as  a  minimum  industry  based  standard  that  must  be  met  and 
serves  to  take  into  account  changes  in  technology  [Ref.  28].  It  is  a  way  for  the  SR  and  SP 
to  validate  their  relationship  and  prove  SP  value  over  time  [Ref.  24].  Setting  benchmarks 
for  the  requirements  not  only  accommodates  technology  advances,  but  also  allows  for 
monitoring  contractor  compliance  with  the  requirements  to  keep  up  with  technological 
changes  [Ref.  28]. 
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For  SRs  seeking  to  understand  how  well  their  sourcing  relationship  is  perfonning, 
a  comprehensive  benchmarking  program  can  be  critical  to  the  continuing  success  of  the 
outsourcing  relationship.  Identifying  and  monitoring  areas  of  strength  and  weakness 
facilitates  a  proactive  dialogue  between  an  SP  and  its  SR  and  helps  ensure  that  the 
strategic  goals  of  the  SP  and  SR  are  known,  aligned,  and  remain  achievable  during  the 
course  of  the  relationship  [Ref.  24],  In  the  benchmarking  process  for  an  outsourcing 
engagement,  the  SP  price  and  SR  retained  costs  are  combined  and  compared  to  a  peer 
group  of  organizations  with  similar  complexities  and  workloads.  A  process  is  put  in 
place  to  ensure  the  peer  groups  selected  are  truly  comparable  and  the  quantitative 
comparisons  developed  are  defensible.  William  Maurer  et  al.  state  that  this  process  is  an 
assessment  of  risk  transfer  that  is  accepted  by  the  SP  at  the  time  the  two  parties  engaged 
in  the  relationship  during  Phase  3  of  the  Strategic  Sourcing  process.  The  risk  transfer  in 
most  outsourcing  contracts  consists  of  items  such  as  responsibility  and  control;  service- 
level  agreements;  and  contractual  recourse  through  penalties. 

William  Maurer  indicates  that  an  SR/SP  benchmark  must  place  a  value  on  these 
risk  transfer  elements  and  ensure  that  they  are  accounted  for  in  peer  group  comparisons 
[Ref.  24].  Assigning  value  and  accountability  can  occur  in  one  of  two  ways:  “the  peer 
group  can  consist  of  similar  outsourced  engagements,  or  a  peer  group  of  organizations 
with  similar  workloads  and  complexities”  [Ref.  24].  Once  a  valid  peer  group  is  identified 
with  the  appropriate  level  of  risk  transfer  factored  into  the  equation,  the  comparison  of 
price  plus  retained  costs  can  be  made.  Using  these  comparisons  will  likely  reveal 
opportunities  for  improvement,  illustrate  where  the  relationship  falls  according  to 
industry  comparisons,  and  provide  the  SR  with  a  level  of  awareness  on  whether  they  are 
getting  the  most  ‘bang  for  their  buck.’ 

Outsourcing  theorists  believe  that  benchmarking  can  change  the  relationship  and 
the  pricing  strategies  between  the  SR  and  the  SP.  While  benchmarking  provides  a 
marketplace  price  and  service  comparison,  it  also  provides  a  certain  level  of  comfort  that 
any  the  long-term  agreements  will  remain  aligned  with  the  market  conditions.  The 
rapidly  changing  IT  environment  requires  the  consideration  of  annual  benchmarking  to 
ensure  that  the  pricing  and  services  are  also  modified  with  the  changes  in  the  marketplace 
conditions. 
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3.  Service-Level  Agreements 

As  the  number  of  organizations  outsourcing  IT  functions  continues  to  grow,  these 
organizations  are  constantly  seeking  ways  to  reduce  cost  and  improve  service  in  their 
outsourcing  endeavors.  One  of  the  lessons  learned  from  outsourcing  is  the  critical  need 
to  establish  performance  monitoring  and  have  the  right  service  levels,  both  of  which  are 
considered  subsets  of  performance  management.  This  provides  visibility  into  the  SP’s 
performance,  ensures  that  service  levels  support  the  continuous  attainment  of  business 
objectives,  and  drives  the  desired  SP  behavior  [Ref.  30].  Performance  management  is 
broadly  defined  as  “the  activities  and  processes  needed  to  determine  if  the  contract  is 
being  satisfactorily  executed”  [Ref.  29].  More  specifically,  it  is  the  process  of  monitoring 
vendor  performance  against  the  contractual  requirements. 

Performance  management  can  be  categorized  as  either  strategic  or  tactical. 
Strategic  performance  management  is  concerned  with  higher-level  organizational  goals 
including  overall  costs,  schedules,  and  performance  goals.  Conversely,  tactical 
performance  management  is  concerned  with  the  SP’s  performance  against  the  specific 
itemized  services.  For  this  reason,  tactical  performance  management  is  routinely 
categorized  as  “service  level  performance  management.”  [Ref.  29] 

Performance  measures  are  commonly  used  to  detennine  whether  a  SP  is  meeting 
the  performance  standards  established  in  the  contract.  These  measures  can  be  both 
quantitative  and  qualitative.  However,  the  most  effective  measures  are  quantitative.  By 
definition,  performance  measures  should  be  specific,  objective,  and  verifiable  to 
minimize  the  opportunity  for  dispute.  Additionally,  they  should  include  only  items  that 
are  the  sole  responsibility  of  the  SP,  to  minimize  disputes  pertaining  to  task  ownership.  It 
is  often  beneficial  to  bind  incentives  and/or  penalties  to  the  perfonnance  measures.  This 
emphasizes  their  importance  to  the  organization  while  encouraging  the  SP  to  exceed  the 
organization’s  expectations. 

Many  IT  contracts  include  perfonnance  measures  ingrained  in  the  description  of 
service  levels  and  defined  and  managed  through  the  use  of  service-level  agreements 
(SLAs).  A  SLA  is  defined  as  a  “contractual  tool  keyed  to  the  customer’s  expectations”  as 
SPs  and  organizations  decide  which  services  will  be  provided  and  what  will  be  the 
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criteria  for  measuring  their  success  and  failure  [Ref.  31].  In  essence,  a  SLA  is  a 
contractual  commitment  to  meet  specific  goals  and  includes  a  pre-defined  perfonnance 
monitoring  methodology.  The  advantages  associated  with  incorporating  SLAs  into  an 
outsourcing  contact  include  providing  the  organization  and  the  contractor  with  a  baseline 
to  measure  performance,  and  establishing  a  method  for  allowing  payments  (via  incentives 
and/or  penalties)  to  be  tied  to  performance,  service  quality,  and  customer  satisfaction. 

William  Maurer  et  al.  have  stated  in  their  research  that  the  foundation  of 
incentives  and  penalties  lies  within  the  service-level  agreement  (SLA)  portion  of  the 
outsourcing  contract  [Ref.  32].  They  further  state  that  “Service-levels  should  be  set  to  the 
minimum  acceptable  level  of  perfonnance  required  to  meet  the  enterprise  business 
objectives.  For  the  service  levels  to  qualify  as  an  SLA  and,  therefore,  an  effective 
foundational  tool  for  managing  the  outsourcing  relationship,  the  service  levels  —  when 
not  met  by  the  ESP  —  must  be  subject  to  contractual  penalties.”  In  their  research,  they 
indicate  that  IT  management  best  practices  dictate  that  service  levels  must  meet  the 
criteria  of  a  five-step  process  to  qualify  as  a  valid  and  usable  measurement  tool.  The  five- 
step  process  is: 

•  Define  the  required  service  levels  to  ensure  maximum  effectiveness  and 
meet  minimum  business  objectives. 

•  Measure  service  activity  results  against  the  defined  service  levels. 

•  Examine  the  results  for  problem  detennination  and  root  cause  analysis. 

•  Take  appropriate  corrective  action. 

•  Continuously  guide  service  activities  to  hold  the  gains  achieved  by  the 
corrective  action  taken. 

While  a  variety  of  performance  measures  can  be  used,  basic  measures  should 

cover  vendor  response  time,  system  availability,  and  system  downtime.  Also,  to  be 

effective,  SLAs  should  be  developed  with  a  focus  on  such  areas  as  completeness, 

reporting  functions,  change  management,  and  consistency  [Ref.  33].  Completeness  refers 

to  outlining  all  of  the  functions  that  are  monitored.  A  common  error  in  writing  SLAs  is 

specifying  too  many  services  to  measure.  It  is  important  to  note  that  every  service  or 

function  does  not  necessarily  require  its  own  SLA.  An  effort  should  be  made  to  measure 

those  services  and  requirements  that  are  deemed  critical  to  organizational  success  and 

those  that  provide  the  most  value  to  its  customers.  This  objective  is  met  by  consolidating 
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requirements  and  measurable  services  so  the  total  number  of  SLAs  is  as  low  as  possible 
without  eliminating  or  overshadowing  the  critical  requirements. 

Reporting  functions  include  reports  that  are  used  to  judge  performance,  how 
frequently  they  are  generated,  and  who  will  receive  them  [Ref.  33].  The  two  categories 
of  reporting  for  SLAs  are  real  time  reporting  and  periodic  reporting.  The  purpose  of  real 
time  reporting  is  to  allow  clients  to  know  the  status  of  the  service  or  network.  Prompt 
notification  should  be  provided  to  the  organization  when  problems  occur.  This 
notification  should  include  the  cause  of  the  problem,  the  impact,  and  the  plan  for 
resolution.  Periodic  reporting  (most  common  in  SLAs)  refers  to  historical  metrics  on 
actual  service  performance  that  are  then  compared  to  the  contract  requirements. 

Change  management  involves  considering  the  dynamics  that  accompany  any  IT 
network  project  and  require  portions  of  the  contract  to  be  amended  or  adapted  to  address 
ongoing  change.  In  a  network  environment,  hardware,  software,  and  users  are  frequently 
added,  deleted,  or  modified.  The  SLAs  should  identify  how  such  changes  will  be 
considered  in  the  performance  requirements  and  performance  measures. 

Consistency  addresses  the  idea  that  SLAs  tend  to  be  complex  and  lengthy; 
therefore  they  should  be  written  to  ensure  that  common  terms  are  used  in  a  consistent 
manner  both  within  the  SLA  and  across  the  enterprise  to  achieve  semantic  harmony. 

Maurer,  Scardino,  and  Young  have  written  that  to  develop  a  set  of  effective 
business-based  service  levels,  organizations  must  use  a  prescribed  service-level  selection 
methodology  based  on  clarity,  rigor,  and  consistency.  The  selection  methodology 
includes: 

•  Functions  -  defining  functional  categories  that  will  be  measured.  This 
section  should  include  any  production  support  required  to  ensure  that  the 
system  produces  the  expected  results.  Also  included  are  user  support 
activities  to  ensure  questions  are  answered,  and  problems  are  researched 
and  user  assistance  is  provided.  Lastly  included  in  this  section  are 
maintenance  and  enhancement  requests. 

•  Activities  -  clearly  describing  activities  in  the  functional  categories 
mentioned  in  the  Functions  category.  The  Activities  section  provides 
greater  technical  and  measurable  detail  for  each  area. 

•  Service-level  components  -  identifying  common  service  levels  seen  in 
various  outsourcing  engagements 
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Gartner  has  developed  a  list  of  the  100  most  common  service  levels  used  by 
enterprises.  The  following  is  an  example  of  how  a  SLA  for  Customer  Satisfaction  might 
be  developed.  [Ref.  32].  Table  2  provides  an  illustration  of  completed  descriptions  of 
several  service  levels  that  apply  to  Customer  Satisfaction  [Ref.  30]. 

•  Category:  Customer  satisfaction  —  ongoing 

•  Explanation:  Measures  performance  of  a  specific  function,  such  as  help 
desk  call  resolution  or  desktop  problem  resolution.  Explanations  are  used 
to  identify  end  user's  opinion  of  service  perfonnance.  The  results  are  used 
to  identify  and  resolve  any  issues  and  problems.  The  resulting  actions 
should  improve  end-user/management  satisfaction  and  service 
performance. 

•  Service  level:  Establish  that  92  percent  are  very  satisfied  or  satisfied.  It  is 
important  to  note  that  the  customer  satisfaction  process  will  not  start  until 
six  months  after  contract  initiation  and  project/activity  initiation. 

•  Responsibilities:  Measure  customer  satisfaction  on  a  daily  basis  by  taking 
less  than  5  percent  of  daily  activities  and  completing  a  customer 
satisfaction  record  per  documented  processes  and  procedures.  The 
sampling  should  be  spread  over  the  various  functional  areas. 

•  Assumptions:  Survey  will  be  completed  via  direct  voice  contact  or  via  e- 
mail.  End  users  will  take  part  on  a  volunteer  basis. 

•  Measure  formula:  The  following  formula  is  valid  for  the  daily  and 
monthly  reporting  periods:  The  number  of  responses  with  a  “very 
satisfied”  or  “satisfied”  rating  divided  by  the  total  number  of  responses 
equals  the  percentage  service  level  attained. 

•  Data  sources:  An  ESP-provided  tool  that  provides  documentation 
capabilities  will  be  used  to  meet  the  reporting  requirements. 

•  Incentive  or  penalty  fonnula:  Variable 
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Category 

Requirements 

Quality 

Service  Level 

Measurement  Formula 

Application 
break'fix 
Priority  1 

Restore 
functionality  of 
critical 
applications 

Less  than  2 
oeroert  rework 
after  completion 
and 

mplementat  on  of 
fix 

Two  business 
hours  resolution 
for  on-shift  96 
percent  of  the 
time.  Twelve 
business  hours 
resolution  for  off- 
shift  93  percent 
of  the  time 

Time  that  the  critical 
application  is  down,  beginning 
with  notification  and  ending 
with  user  acceptance. 

Downtime  less  than  or  equal  to 
two  hours  equals  SLA  met. 
(Weight  factor  plus  all  other 
downtime  incidents  divided  by 
the  total  number  of  incidents 
must  be  greater  than  96 
percent.) 

Application 
break'fix 
Priority  2 

Restore 
functionality  of 
tne  applicator 

Less  than  2 
oeroert  re-work 
after  completion 
and 

implementation  of 
fix 

48  business 
hours  resolution 
for  on-shift  and 
off-shift  94 
percent  of  the 
time 

Time  that  the  critical 
application  is  down,  beginning 
with  notification  and  ending 
with  user  acceptance. 

Downtime  less  than  or  equal  to 
48  hours  equais  SLA  met. 
(Weight  factor  plus  all  other 
downtime  incidents  divided  by 
the  total  number  of  incidents 
must  fce  greater  than  94 
percent.) 

Application 
break'fix 
Priority  3 

Restore 
functionality  of 
tne  applicator 

Less  than  2 
oeroert  rework 
after  completion 
and 

mplementat  on  of 

fix 

Seventy-two 
business  hours 
resolution  for  on- 
shift  and  off-sh  ft 
9C  percent  of  the 
time 

Time  that  the  critical 
application  is  down,  beginning 
with  notif  cation  and  end  ing 
with  user  acceptance. 

Downtime  less  than  or  equal  to 
72  hours  equals  SLA  met. 
(Weight  factor  plus  all  other 
downtime  incidents  divided  by 
the  total  number  of  incidents 
must  fce  greater  than  90 
percent.) 

Source:  Gartner  Research  (November  2004) 


Table  2.  Service-Level  Examples  (From:  Ref.  26). 


4.  Successful  Organizational  Outsourcing  Engagements 

Many  articles  have  been  written  to  highlight  unsuccessful  outsourcing  deals,  but 
less  fanfare  is  given  to  the  successful  ones.  The  following  subsections  describe  two 
successful  IT  outsourcing  partnerships  and  provide  infonnation  regarding  key  factors  in 
their  success. 

a.  City  of  Chicago  Partner  with  Unisys  and  Acxiom 
With  a  newly  elected  mayor  leading  the  charge,  the  City  of  Chicago 
wanted  to  make  some  changes  in  its  business  practices  to  increase  its  effectiveness  for  its 
citizens  and  efficiency  in  its  operation.  The  Mayor  was  looking  for  non-strategic  services 
that  would  be  a  prime  candidate  for  outsourcing  so  that  its  employees  could  focus  on  core 
business  processes.  At  the  request  of  the  Mayor,  Gartner  conducted  an  IT  user 
satisfaction  study  to  establish  a  baseline  of  how  well  its  internal  IT  resources  were 
providing  IT  services  [Ref.  35].  The  City’s  score  of  2.87  on  a  scale  of  5.0  confirmed  that 
the  City  was  performing  less  than  satisfactorily  and  fell  below  the  industry  average 
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benchmark  of  3.56.  This  score  illustrated  that  establishing  an  IT  outsourcing  partnership 
to  manage  the  City’s  key  IT  functional  areas  and  assets  could  provide  significant  value  to 
the  City’s  strategic  objectives. 

The  City  of  Chicago  partnered  with  Unisys  and  Acxiom  to  increase 
service  levels  for  its  customers  and  to  assist  with  controlling  costs.  Acxiom  was 
responsible  for  the  mainframe  outsourcing  and  the  related  functions  such  as  tape  and  disk 
storage  subsystems,  database  support  and  batch  and  online  application  management. 
Unisys  acquired  oversight  for  help  desk  support,  desktop  and  network  management,  and 
asset  management  and  maintenance.  Unisys’  direct  contact  with  end  users  required  the 
company  to  demonstrate  that  it  could  improve  the  customer  satisfaction  rating  as  well  as 
the  service  levels  [Ref.  35]. 

This  commitment  to  improvement  by  Unisys  was  evident  in  its  aggressive 
approach  and  unparallel  concentration  to  improve  its  services  to  the  City.  The 
partnership  began  to  reap  the  benefits  that  accompany  IT  outsourcing  deals  quickly  as 
Unisys  established  a  centrally  managed  helpdesk  where  all  the  problems  or  services  are 
received  and  a  follow-up  and  feedback  loop  for  all  helpdesk  support,  and  constructed  an 
on-site  team  to  provide  desktop,  application  and  network  support.  Additionally,  they 
created  a  Program  Management  Office  for  management  of  on-site  personnel  and  for 
addressing  any  outstanding  issues  that  may  arise  from  key  city  officials  [Ref.  35]. 

Acxiom  implemented  hardware  migration  and  consolidation  efforts  and 
relieved  the  City  of  their  print  and  mail  responsibilities.  They  gained  responsibility  for  a 
host  of  other  IT  functions  that  were  perfonned  by  the  City  of  Chicago  staff. 

These  modifications,  along  with  the  additions  and  modification  made  by 
Acxiom,  enabled  the  City  of  Chicago  to  realize  exponential  improvements  in  customer 
service  and  customer  satisfaction.  A  follow-up  survey  revealed  that  80  percent  of  the 
respondents  were  satisfied  with  the  improved  service-level.  Additional  benchmarking 
was  perfonned  to  provide  quantifiable  measures  on  perfonnance  and  outsourcing 
services. 

The  Mayor  credits  the  success  of  this  partnership  to  several  critical 

success  factors  and  lessons  learned  [Ref.  36]: 
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•  With  an  outsourcing  agreement,  the  organization  must  set  reasonable 
expectations  and  not  sell  the  outsourced  services  as  a  panacea  that  will  fix 
all  of  the  problems  quickly. 

•  Develop  strength  around  contract  vendor  management.  The  retained  staff 
members  need  different  skills  to  manage  the  outsourced  contracts  than  was 
required  internally  to  manage  employees  and  address  operational 
problems. 

•  Incorporate  end  users  in  the  process  from  the  beginning,  but  expect  and 
accept  resistance  to  the  change. 

•  The  vendor  use  of  an  on-site  project  management  team  is  helpful  and  can 
ease  the  transition  process. 

•  Use  service-level  agreements  that  are  focused  on  time,  cost  and  quality, 
such  as  closed  call  time,  end-user  satisfaction  and  network/application 
performance. 

•  Develop  a  contract  that  encourages  gain  sharing.  If  the  vendor  can  bring  in 
new  innovation  and  agree  to  share  some  of  the  cost  savings. 

•  Cultivate  CEO-level  support.  It  is  essential  that  the  top  executive  be 
committed  to  the  outsourcing  effort  to  ensure  enterprise  cooperation. 

•  Pick  vendors  that  will  be  long-tenn  partners.  If  the  vendors  are  not 
committed  to  working  with  the  organization  as  a  partner,  the  relationship 
will  become  a  deal  without  flexibility  and  will  grow  stagnate  over  time. 

b.  Nike  Partner  with  Lockheed  Martin 

Nike  and  Lockheed  Martin  developed  an  outsourcing  partnership  in  April 
1999  where  Nike  would  relinquish  management  and  ownership  responsibilities  for  its 
internal  Corporate  Information  Technology  services  [Ref.  34].  Nike  desired  to  outsource 
its  Information  Technology  (IT)  services  at  a  time  when  it  was  decreasing  in  market- 
share  so  the  creativity  and  talent  of  its  personnel  could  ultimately  focus  on  the  core 
athletic  businesses  while  enhancing  competitiveness  through  greater  focus  on  product 
superiority  and  customer  service.  These  services  include  desktop  support,  data  center, 
network  management,  help-desk  services,  and  technical  asset  management  operations. 

Bert  Liverance,  Director  Global  IT  Operations  for  Nike,  indicated  that  the 
key  to  the  success  of  his  Nike’s  outsourcing  endeavor  was  realizing  that  a  good 
outsourcing  relationship  takes  work.  As  the  relationship  matures,  periodically  it  makes 
sense  to  take  the  time  to  evaluate  the  perfonnance  and  objectives  of  your  partnership. 
Check  the  alignment  and  all  the  vital  connections.  For  no  matter  how  good  the 
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relationship  is,  there  is  always  room  for  improvement.  Timely  identification  of  these 
opportunities  helps  to  ensure  a  strong  ongoing  relationship  [Ref  34].  Liverance  further 
attributes  the  partnerships  success  to  development  of  a  process  to  evaluate  and 
benchmark  the  outsourcing  relationship  to  drive  performance  improvements.  By 
realizing  that  any  relationship  will  not  reach  perfection  at  its  inception,  both  parties 
agreed  that  a  procedure  to  detennine  and  measure  the  qualitative  and  quantitative 
characteristics  of  the  relationship  was  necessary.  Finally,  as  Nike’s  business 
requirements  changed,  the  partnership  and  certain  aspects  of  the  contract  needed  to  be 
dynamically  linked  to  prevent  stagnating  Nike’s  competitive  edge. 

C.  COMMERCIAL-OFF-THE-SHELF  APPLICATION  ANALYSIS 

The  increase  in  the  use  of  IT  systems  and  web-based  technologies  has  forced 
organizations  to  change  the  way  they  conduct  business.  They  must  now  find  new  ways 
and  new  tools  to  control  access  to  organizational  resources  securely.  Additionally, 
organizations  must  be  able  to  manage  increased  security  risks  associated  with  the 
escalating  volume  of  user  administration.  To  succeed  in  these  areas,  a  comprehensive 
and  integrated  security  solution  must  be  built  into  their  networking  strategy. 

While  there  are  many  applications  and  resources  that  can  assist  in  building  a  more 
secure  network,  an  Identity  and  Access  Management  (IAM)  solution  is  believed  to  be 
ideal  for  use  in  minimizing  duplicate  accounts,  the  need  for  multiple  accounts,  and  thus 
increase  CLIN  0024’s  in  the  Navy  Marine  Corps  Intranet  (NMCI)  networking 
environment.  Enterprise  IAM  can  be  defined  as  a  set  of  processes  and  technologies  to 
manage  user  objects  more  effectively  and  consistently  over  relatively  large  numbers  of 
systems  and  directories  [Ref.  36].  When  fully  integrated  with  the  network,  an  enterprise 
IAM  solution  is  best  as  it  eliminates  multiple  accounts  by  assigning  multiple  user 
identities  and  roles  to  a  single  account.  It  also  enables  administrators  to  establish  security 
settings  to  disallow  the  creation  of  a  duplicate  account  based  on  the  user’s  credentials. 
The  enterprise  IAM  solution  has  a  host  of  other  functionalities  that  will  not  be  mentioned 
in  this  thesis,  but  should  be  reviewed  to  appreciate  and  gain  full  benefit  of  the  power  this 
solution  possesses. 
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1.  Overview  of  Identity  and  Access  Management 

Identities  are  pieces  of  information  that  identify  a  user’s  existence  [Ref.  37].  To 
allow  users  to  utilize  and  benefit  from  the  many  applications  and  services  offered, 
organizations  of  all  types  assign  identifiers,  or  unique  codes,  to  individuals  in  order  to 
represent  their  uniqueness  to  the  organization  and  easily  map  to  applications  and  services. 
Individuals  take  on  multiple  roles  using  these  identifiers  as  their  digital  identities  as  they 
traverse  through  the  organization.  These  identities,  or  roles,  may  change  depending  on 
the  task,  but  the  uniqueness  maps  back  to  the  original  identifier  of  the  user. 

Managing  user  identities  and  identifiers  across  an  enterprise  has  become  crucial  to 
network  security  as  leaner  staffs  are  now  required  to  take  on  several  roles  to  meet  the 
organizational  mission.  The  proliferation  of  identities  has  also  increased  the  need  to 
manage  access  to  organizational  assets.  Success  in  managing  organizational  assets 
depends  on  the  integrity,  confidentiality,  and  privacy  of  its  information  and  processes 
with  the  ability  to  audit  governance,  compliance,  and  use  [Ref.  37].  Organizational 
systems  today  have  become  easily  accessible  creating  the  need  to  implement  fine¬ 
grained,  policy-based  protection  to  protect  their  mission-critical  data  and  services. 
Additionally,  identities  need  to  be  managed  to  facilitate  the  right  access  to  the  right 
resources  or  users.  Without  properly  managing  these  identities,  a  user  may  be  given 
access  to  applications  or  resources  that  were  not  deemed  necessary  for  the  performance 
of  his  or  her  job.  Organizations  must  ensure  they  control  and  audit  the  process  of  issuing 
a  user  credential,  or  allowing  access  to  files,  databases  or  Internet  services.  Effective 
identity  and  access  management  should  consider  a  single  view  of  all  activities,  such  as 
user  management  and  policy  management,  or  creating  a  new  user  account.  This  will 
eliminate  the  need  for  the  use  of  multiple  consoles  or  applications  when  adding, 
modifying,  or  deleting  users  or  specific  information  about  the  user,  the  user’s  role,  or 
identity. 

2.  Identity  and  Access  Management  Tools 

Many  IAM  tools  combine  several  functional  components  to  create  a  best-of-breed 
solution.  This  solution  provides  maximum  business  value  by  integrating  these 
components,  yet  making  them  interoperable  with  components  from  other  vendors  or  with 
custom-developed  applications  [Ref.  36],  Organizations  are  then  enabled  to  choose  a 
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fully  integrated  solution  from  a  single  vendor  (called  a  suite),  to  combine  selected 
components  from  different  vendors  that  will  work  together  (the  real  benefit  of  best-of- 
breed),  or  to  phase  in  the  pieces  of  a  complete  IAM  solution  using  an  evolutionary 
approach.  Many  IAM  solutions  include  provisioning,  policy  enforcement  (security),  and 
end-to-end  auditing  to  assist  in  ensuring  that  all  aspects  of  the  identity  life  cycle  are 
securely  and  efficiently  managed  [Ref.  36]. 

Provisioning  is  defined  as  “the  automation  of  business-oriented  work  flow  of 
systems,  resources,  services  and  devices  to  employees,  partners,  contractors,  suppliers 
and  temporary  workers.”  [Ref.  38]  User  provisioning  is  the  process  for  managing  user 
identity  enterprise-wide  and  beyond.  User  provisioning  encompasses  the  identification 
of: 

•  The  types  of  users  an  organization  will  manage 

•  The  systems,  application,  and  other  business  resources  those  users  will 
need  to  access 

•  The  levels  of  access  to  those  resources  users  will  need 

•  How  the  organization  will  create,  update,  and  delete  user  accounts 

•  How  the  business  will  guarantee  secure  access  to  its  resources 

Provisioning  of  user  objects,  monitoring  of  all  activities,  reporting  of  all 

transactions,  and  de-provisioning  (or  un-assigning)  of  user  objects  are  fundamental 
concepts  of  user  life  cycle  management  [Ref.  38],  Organizations  need  to  manage  digital 
identities  across  the  entire  enterprise,  and  securing  access  to  files,  directories  and 
databases  while  monitoring  all  of  these  activities  with  an  end-to-end  audit.  Where 
provisioning  differentiates  from  standard  manual  practices  is  that  when  user  access  is  no 
longer  required,  access  rights  to  all  systems,  devices,  files  and  so  on  are  terminated. 

Provisioning  would  be  very  ineffectual  without  the  implementation  of  security 
management.  The  fundamental  business  process  for  which  work  flow  is  dynamically 
generated  must  support  the  organization’s  security  policies  and  business  practices  for 
which  the  provisioning  of  users  is  being  conducted  [Ref.  38].  With  the  use  of  this 
technology,  the  user  information  can  be  used  to  create  a  profile  of  a  person  or  role  that 
indicates  exactly  what  resources  should  be  allocated  to  the  person  or  role.  Any  changes 
made  to  the  profile  can  automatically  trigger  provisioning  or  de-provisioning  activity 


85 


with  little  interaction  required  from  the  manager  [Ref.  38],  When  a  user  moves  to 
another  command  unit,  all  of  the  necessary  work  flow  items  would  start  and  proceed  to 
the  reassignment  of  provisioned  items,  based  on  approvals  received  and  any  external 
systems,  for  instance  the  Human  Resources  department  or  military  Manpower  division. 

Most  organizations  desire  to  maintain  a  history  of  the  types  of  events  that  have 
occurred  when  managing  a  user  account.  Performing  auditing  functions  using  the 
provisioning  system  helps  ensure  that  all  events  and  activities  associated  with  identities 
or  resources  are  tracked.  Auditors  can  see  “when  an  identity  was  created,  who  created  it, 
where  the  identity  went,  what  it  accessed,  what  it  touched,  into  what  it  morphed,  when  it 
was  suspended  and  by  whom,  and  when  it  was  terminated”  [Ref.  38].  Auditing  services 
tracks  all  provisioning  activity  across  the  entire  enterprise  and  extended  enterprise. 

While  an  analysis  of  a  multitude  of  vendors  that  advertised  their  IAM  solution 
was  conducted,  only  a  couple  truly  demonstrated  a  solution  that  was  integrated  and 
contained  the  IAM  capabilities  mentioned  above.  These  two  companies,  Computer 
Associates  and  IBM,  are  currently  considered  industry  leaders  in  IAM  technology.  Of 
the  two,  Computer  Associates  offered  the  most  comprehensive  solution,  which  included 
not  only  the  tools  mentioned  above,  but  also  a  wealth  of  additional  easy-to-integrate 
components  that  could  further  enhance  the  network  management  experience. 

D.  CONCLUSION 

This  chapter  provided  a  detailed  analysis  of  industry  accepted  and  best  practices 
associated  with  IT  outsourcing  contracts.  It  outlined  Gartner’s  phased-approach  to 
outsourcing,  called  the  Strategic  Sourcing  process,  and  explained  the  importance  of 
benchmarking  and  performance  management  in  fostering  successful  partnerships  in 
Phases  3  and  4  of  the  process. 

In  particular,  it  expressed  the  importance  of  creating  and  monitoring  SLAs  using 
the  following  guidelines.  Align  outsourcing  service  levels  to  the  business  requirements; 
use  the  minimum  number  of  service  levels  required  to  ensure  satisfaction  of  the  business 
requirements;  ensure  that  financial,  penalties,  and  incentives  are  included  and  that  they 
align  with  the  business  requirements  of  the  deal;  and  use  a  consistent  approach  when 
measuring  perfonnance  via  service  levels.  While  it  is  clear  that  establishing  the 
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performance  measures  for  an  outsourcing  contract  is  a  daunting  task,  it  is  perhaps  the 
most  critical  challenge  to  outsourcing  success  perfonned  in  Phases  3  and  4  of  the 
Strategic  Sourcing  process.  The  two  successful  outsourcing  endeavors  included  in  this 
chapter  confirms  that  careful  SLA  development,  incorporating  benchmarking  into  the 
contract  and  a  host  of  other  factors  are  imperative  to  ensure  the  success  of  the 
partnership. 

While  there  are  several  point  products  (or  multi-vendor  solutions)  that  could  be 
used  to  tackle  the  NMCI  account  management  challenge,  it  is  recommended  that  an 
integrated  IAM  solution  be  considered  to  assist  with  account  and  access  provisioning  and 
management. 
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VI.  CONCLUSION  AND  RECOMMENDATION 


A.  INTRODUCTION 

This  chapter  provides  a  summary  of  the  previous  chapters  by  furnishing  answers 
to  the  primary  and  secondary  research  questions  presented  in  Chapter  I.  Additionally 
contained  within  this  chapter  are  conclusions  developed  from  the  analysis  of  the  Navy 
Marine  Corps  Intranet  (NMCI)  account  management  process  and  the  associated 
challenges.  The  resulting  research  and  analysis  enabled  the  author  to  make  clear  and 
concise  recommendations  on  specific  areas  of  improvement  to  minimize  additional  costs, 
improve  effectiveness,  and  maximize  value  within  the  enterprise. 

B.  RESEARCH  QUESTIONS 

As  outlined  in  Chapter  I  and  subsequently  addressed  in  the  preceding  chapters, 
the  answers  to  the  research  questions  are  represented  in  the  following  paragraphs.  This 
section  will  include  answers  to  the  secondary  research  questions  while  the  primary 
research  question  will  provide  a  high-level  answer  in  this  section  with  a  more  detailed 
solution  in  the  sub-section  titled  “Recommendation”. 

1.  Primary  Research  Question 

a.  How  Might  the  U.S.  Navy  Reserve  Component  (USN  RC) 
Effectively  Manage  Accounts  in  the  NMCI  Environment? 

There  are  several  areas  outlined  in  the  research  that  demonstrate  process 
inefficiency  and  therefore  are  candidates  for  change.  Some  of  these  include  the  definition 
of  “the  enterprise;”  the  coupling  of  accounts  to  seats;  the  current  management  process 
which  causes  the  creation  of  Contract  Line  Item  0024s  (CLIN  0024s)  for  additional 
accounts  and  the  generation  of  CLIN  0026s  for  Move  Add  Change  (MAC)  requirements; 
and  the  use  of  multiple  stove-piped  Information  Technology  (IT)  solutions.  In  order  to 
mange  not  only  accounts  but  the  entire  NMCI  environment  effectively,  major  changes 
should  be  considered  in  the  tenns  of  the  contract  and  the  corporate  business  rules.  A 
detailed  analysis  of  the  changes  and  the  recommendations  for  improvement  are  included 
in  the  sub-section  titled  “Recommendation.” 
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2.  Secondary  Research  Questions 

a.  How  Were  the  Accounts  Allocated  during  NMCI  Deployment? 

In  the  beginning  stages  of  NMCI  deployment,  many  commands  allocated 
accounts  by  creating  local  processes  of  assigning  accounts  to  seats.  Earlier  business  rules 
required  that  each  seat  have  at  least  one  account  assigned,  therefore  technical 
representatives  were  required  to  list  all  seats  manually  and  subsequently  manually  cross- 
reference  personnel  accounts  back  to  each  seat.  Ensuring  that  each  seat  had  at  least  one 
account  was  a  cumbersome  process  that  was  labor-intensive  and  in  some  cases  required 
multiple  personnel  to  perform.  With  little  guidance  and  no  standardized  IT  solution, 
most  were  required  to  create  manual  processes  and  use  whatever  IT  resources  they  had 
locally  available. 

As  the  NMCI  deployment  began  to  increase  rapidly  and  commands  began 
to  cutover  at  record  pace,  the  Department  of  the  Navy  (DoN)  slowly  began  to  realize  how 
inefficient  the  process  was  and  requested  the  creation  of  an  IT  solution  to  help  ease  the 
management  nightmare.  Over  time,  several  IT  solutions  were  created  to  handle  different 
functions  within  the  overall  process  (see  Chapter  III  for  more  detail).  While  these 
systems  lighten  some  of  the  burden,  they  created  additional  layers  for  the  technical 
representatives  and  further  complicated  the  overall  management  process.  These 
additional  layers  or  stove-piped  systems  required  technical  representatives  to  enter  data  in 
the  NMCI  Enterprise  Tool  (NET)  at  deployment.  Once  a  command  was  cutover,  account 
requests  and  all  other  service  requests  were  performed  using  the  Service  Request 
Electronic  Form  (SR  eForm).  Billing  and  auditing  functions  resided  in  Electronic  Market 
(eMarketplace). 

These  are  considered  the  corporate  or  enterprise-level  systems,  however 
none  of  them  can  be  considered  an  accurate  central  data  repository.  With  all  these 
solutions,  technical  representatives  are  still  required  to  maintain  a  locally  generated 
central  data  repository  to  consolidate  and  effectively  track  resources  for  which  they  have 
overall  management  responsibility. 
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b.  How  Are  the  USN  RC  Customer  Technical  Representatives 
(CTRs)  Currently  Tracking  NMCI  Accounts  per  Region? 

Chapter  IV  provides  a  detail  analysis  of  the  As-Is  process  for  the  NMCI 
account  management  process.  The  principles  of  Business  Process  Redesign  (BPR)  as 
defined  by  Omar  El  Sawy  and  the  Knowledge- Value  Added  (KVA)  methodology  created 
by  Housel  and  Bell  were  used  to  capture  and  illustrate  the  As-Is  process  and  to 
quantitatively  determine  the  amount  of  value  that  each  sub-process  provides  to  managing 
accounts.  Surveys,  site  visits,  and  interviews  were  the  primary  means  of  data  collection 
in  an  effort  to  capture  the  current  process.  However,  the  data  collection  revealed  there  is 
no  standardized  method  for  tracking  accounts  either  across  the  enterprise  or  within  the 
regions. 

While  there  was  no  standardized  process,  four  scenarios  and  numerous 
sub-processes  showed  some  commonality  across  the  regions  and  these  sub-processes 
were  used  to  devise  the  As-Is  model.  As  previously  mentioned,  the  technical 
representatives  were  required  to  use  many  manual  processes  such  as  manual  logbooks 
when  in-processing  and  out-processing  Users  and  phone  calls  to  Users  to  verity  possible 
name  matches  in  the  Global  Address  List  (GAL).  Additionally,  all  requests  that  required 
contractor  action  had  to  be  submitted  to  the  next  higher  technical  representative  in  the 
organizational  chain  of  command.  At  the  beginning  of  this  research,  these  requests  were 
sent  via  email,  but  recently  the  sub-process  was  modified  to  allow  entry  into  the  web- 
based  SR  eLonn. 

Asset  management  and  some  account  management  were  performed  in 
NET  while  asset  and  account  invoice  auditing  were  perfonned  using  eMarketplace. 
Other  systems  like  Active  Directory  and  the  GAL  were  used  to  verify  account  status. 
While  automation  has  been  incorporated  into  the  process,  none  of  the  systems  have  been 
integrated  to  allow  data  to  be  exchanged  seamlessly  or  synchronized  to  enable  the  data 
integrity  amongst  all  the  platfonns.  This  has  required  the  technical  representatives  to 
input  common  data  and  pull  inaccurate  data  from  each  system.  Currently,  the  use  of 
multiple  stove-piped  IT  systems  (both  locally  and  web-based)  have  become  the  IT 
solution  of  choice,  yet  the  process  continues  to  be  labor-intensive  and  ineffective. 
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c.  How  is  the  Navy  Reserve  Forces  Command  Currently  Managing 
NMCI  Accounts  for  the  USNRC? 

Chapter  IV  also  provides  a  detail  analysis  for  this  question.  When  acting 
in  the  capacity  of  an  assistant  or  deputy  technical  representative  (ACTR/DCTR),  the 
Navy  Reserve  Forces  Command  has  been  required  to  manage  accounts  using  similar 
processes  and  the  same  IT  tools  identified  under  the  previous  question.  They  have  used 
the  same  solutions  but  have  had  access  to  a  higher-level  management  view  within  the 
web-based  systems.  Since  they  have  had  overall  responsibility  for  all  of  the  USN  RC, 
they  have  been  required  to  review  orders  before  final  submission,  make  approvals  and 
disapprovals,  and  forwarded  major  requests  to  the  contractor.  Again,  these  functions 
have  been  accomplished  using  the  same  stove-piped  web-based  IT  solutions  previously 
mentioned  and  by  using  email  and  phone. 

d.  How  is  the  U.S.  Navy  Active  Component  (USN  AC)  Currently 
Managing  NMCI  Accounts? 

Phone  conferences  with  USN  AC  representatives  in  the  office  of  the 
Director  of  NMCI  confirmed  that  the  USN  AC  has  been  managing  accounts  using  the 
same  IT  systems  and  tools  used  by  the  USN  RC.  The  process  of  performing  these  tasks 
may  differ  as  there  has  been  no  standardized  process  or  policy  by  either  higher  echelon 
command.  While  capturing  the  process  for  the  USN  AC  is  out  of  the  scope  of  this  thesis, 
a  similar  approach  using  the  BPR  principles  and  KVA  methodologies  is  recommended  to 
understand  exactly  how  the  process  is  performed. 

e.  How  are  Some  of  the  Large  Commercial  Companies,  which  Have 
Adopted  the  Seat  Management  Concept,  Successfully  Managing 
Accounts  across  an  Enterprise  Solution? 

Chapter  V  identifies  a  phased  approach  to  strategic  outsourcing  and  seat 
management.  The  approach  discussed  in  this  research,  called  the  Strategic  Sourcing 
Process,  has  become  widely  accepted  by  corporate  America  and  has  gained  recognition 
as  an  industry  best  practice  for  IT  outsourcing.  The  process  outlines  four  key  phases 
(Sourcing  Strategy,  Evaluation  and  Section,  Contract  Development,  and  Sourcing 
Management)  and  identifies  key  functions  that  must  be  considered  in  each  of  these 
phases.  One  key  aspect  of  the  phased-approach  is  the  establishment  and  evolution  of  a 
true  “partnership”  between  the  service  provider  (SP)  and  service  recipient  (SR). 
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Incorporating  active  and  continuous  benchmarking  as  well  as  the 
establishment  of  clear  and  concise  Service-Level  Agreements  (SLAs)  have  proven  the 
key  to  outsourcing  and  seat  management  success.  Using  benchmarking  to  determine  how 
well  the  partnership  is  working  enables  the  SR  to  gauge  the  SP’s  perfonnance  by 
comparing  it  to  other  organizations  that  are  of  equal  size,  complexity,  and  outsourcing 
functions.  Many  corporate  companies  also  equate  their  success  in  outsourcing  to  the 
development  of  SLAs.  Using  SLAs  as  a  contractual  measure  and  monitor  of  performance 
to  ensure  that  the  contractor  meets  or  exceeds  the  expectations  of  the  organization  is  also 
critical  for  meeting  the  mission  of  the  organization.  Chapter  V  provides  more 
information  about  benchmarking  and  SLAs  and  therefore  will  not  be  repeated  in  this 
section. 

f.  What  are  the  ‘Best-Of-Breed’  COTS  Products  Used  by  Industry 
for  Account  Management? 

Although  a  true  enterprise  solution  that  could  handle  all  the  functionality 
required  for  NMCI  management  could  not  be  found,  the  Identity  and  Access 
Management  (IAM)  solution  could  be  used  to  tackle  most  of  the  identified  problems 
associated  with  managing  accounts.  An  IAM  solution  is  capable  of  managing  user 
accounts,  identities,  roles,  and  directory  access  across  multiple  platforms  to  create  a  best- 
of-breed  solution.  By  using  provisioning  technology  to  manage  user  objects,  administer 
digital  identities,  and  to  monitor  the  user’s  activities  and  history,  the  CLIN  0024s  created 
because  of  duplicate  accounts  and  multiple  accounts  could  be  dramatically  reduced. 

C.  RECOMMENDATIONS 

This  section  includes  a  more  detailed  response  to  the  primary  thesis  question 
“How  might  the  U.S.  Navy  Reserve  Component  (USN  RC)  effectively  manage  accounts 
in  the  NMCI  environment?”  and  the  secondary  question  “What  would  be  a  feasible  non¬ 
technical  solution  that  the  USN  RC,  and  perhaps  the  USN  AC,  could  implement?” 

1.  The  Proposed  ‘Radical’  Solution 

To  develop  the  proposed  solution,  the  principles  of  BPR  discussed  in  Chapter  IV 
and  defined  by  El  Sawy  were  used.  Additionally,  Housel  and  Bell’s  KVA  methodology 
was  used  to  calculate  the  Return  on  Knowledge  (ROK)  for  each  new  or  modified  sub¬ 
process.  The  specified  business  rules  for  the  NMCI  account  management  process  limit 

the  adoption  of  many  aspects  of  the  To-Be  proposed  solution  in  Chapter  IV.  Therefore,  a 
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‘radical’  solution  has  been  designed  that  will  dramatically  change  the  manner  in  which 
account  management  is  currently  performed.  Levels  of  efficiency  and  costs  savings  will 
exponentially  increase  with  the  implementation  of  this  proposal. 

The  ‘radical’  zero-based  review  process  assumes  that  the  current  business  rules  do 
not  exist  and  that  contracts  can  be  modified  based  on  the  following  recommendations  for 
drastically  changing  the  account  management  process: 

•  Redefine  the  ‘enterprise’  to  consolidate  the  USN  AC  and  the  USN  RC 
budgets  and  NMCI  funding  and  management  oversight.  If  accounts 
are  to  remain  coupled  with  seats,  the  enterprise  should  be  redefined  and 
accounts  should  be  pooled  just  as  initially  intended  (see  Chapter  III).  This 
will  allow  the  USN  RC  complete  access  to  any  unused  accounts  derived 
from  seats  of  the  USN  AC. 

•  Overall  NMCI  management  responsibility  will  reside  at  the  USN 
Echelon  II  level,  truly  demonstrating  the  “One-Navy”  envisioned  by 
senior  leadership. 

•  Establish  a  standard  policy  for  implementation  across  the  claimancy. 

The  survey  results  showed  that  the  technical  representatives  not  only  need 
guidance,  but  have  requested  that  policies  and  procedures  be  established. 

•  Train  the  users  on  how  to  use  the  current  IT  tools  and  any  tools  that 
may  be  mandated  in  the  future.  Again,  the  surveys  and  the  site  visit 
revealed  that  users  are  not  aware  of  the  functionality  and  procedures  of 
important  management  tools  such  as  NET,  SR  eForm,  and  Active 
Directory  structure.  These  applications  and  databases  are  critical  to 
successful  account  management  and  if  not  used  properly,  will  reduce 
efficiency  and  USN  RC  will  continue  to  incur  unnecessary  CLIN  0024 
and  CLIN  0026  costs. 

•  Renegotiate  NMCI  contract  to  decouple  seats  from  accounts.  Taking 
into  consideration  the  cost  of  hardware  vs.  the  cost  of  an  account,  contract 
renegotiation  could  reduce  overall  spending  on  NMCI  accounts  while 
simplifying  the  management  process.  Attaching  personnel  (i.e.,  accounts) 
to  hardware  (i.e.,  seats)  in  such  a  dynamic  organization  as  the  DoN  will 
continue  to  be  a  management  nightmare  as  people  are  constantly 
relocating.  For  example,  consider  increasing  the  cost  of  a  seat  by  what  it 
currently  costs  to  manage  the  two  ‘free’  accounts.  The  cost  of  the 
accounts  would  then  be  decreased  to  compensate  for  the  increase  in  seat 
cost.  The  cost  and  the  method  of  calculation  should  be  agreed  upon  by  the 
government  and  the  contractor.  Attaching  personnel  (i.e.,  accounts)  to 
hardware  (i.e.,  seats)  in  such  a  dynamic  organization  as  the  DoN  could 
continue  to  be  a  management  nightmare  as  people  are  constantly 
relocating. 
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•  Create  an  integrated  web-based  solution,  which  is  thoroughly  beta- 
tested  with  investments  made  in  the  upfront  requirement  analysis  to 
ensure  the  solution  meets  the  user’s  needs.  The  solution  should 
contain  the  functional  and  quality  attributes  required  for  overall 
NMCI  management.  This  tool  should  combine  all  functions  of  NET,  SR 
eFonn,  eMarketplace,  and  any  contractor-specific  systems.  One  tool 
promotes  data  integrity  and  ease  of  management. 

•  To  assist  in  defining  the  requirements  for  such  a  tool,  the  author  has 
created  a  detailed  Functional  Requirements  document  that  includes  not 
only  the  required  functionality  for  the  government,  but  also  the  minimum 
requirement  for  the  contractor’s  interface.  See  Appendix  D.  Additionally, 
Appendix  E  contains  a  Detail  Design  document  to  illustrate  a  functionality 
that  was  included  in  the  web-based  prototype  of  the  requirements.  Each 
web-page  or  view  in  Appendix  E  is  traceable  back  to  each  requirement 
from  Appendix  D. 

•  Once  an  integrated  system  has  been  created,  provide  an  automatic 
interface  between  it  and  existing  legacy  databases  in  Navy  Standard 
Integrated  Personnel  Systems  (NSIPS)  or  Defense  Enrollment 
Eligibility  Reporting  System  (DEERS)  and  the  civilian  personnel 
management  system  equivalent.  Make  use  of  a  unique  identifier  such  as 
Social  Security  Number  w/Common  Access  Card  (CAC)  to  update  the 
management  system,  Active  Directory,  and  NMCI  (in  lieu  of  the  current 
MAC  process)  automatically  as  the  User  transfers  from  command  to 
command  throughout  his  or  her  career. 

•  Strong  consideration  should  be  made  in  the  implementation  of  the 
COTS  enterprise  IAM  solutions  mentioned  in  the  previous  chapter. 

These  solutions  directly  address  many  of  the  account  management  issues 
previously  mentioned  and  could  provide  an  immediate  gain  in  efficiency 
while  decreasing  the  $35  million  paid  for  additional  accounts.  IBM  and 
Computer  Associates  are  industry  leaders  in  the  IAM  solution  and 
therefore  should  be  contacted  on  the  feasibility  of  implementation. 

Implementation  of  these  recommendations  would  eliminate  most  account 
management  responsibilities  currently  performed  by  technical  representatives.  The 
technical  representatives  would  only  be  responsible  for  the  maintenance  and  tracking  of 
hardware. 

Figure  28  depicts  what  the  process  flow  would  entail  if  these  recommendations 
were  accepted  and  implemented.  As  demonstrated,  this  would  significantly  simplify 
NMCI  account  management  and  would  require  little  intervention  by  the  users.  Again, 
this  recommendation  assumes  a  level  of  system  interface  that  does  not  currently  exist. 
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Radical  Process  Recommendation 
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Figure  28.  Radical  Process  Flowchart. 


Figure  29  illustrates  the  ‘radical’  KVA  analysis  based  on  the  proposed  process 
flow  in  Figure  28.  The  spreadsheet  shows  a  relative  comparison  in  the  ROK  between  the 
As-Is  and  To-Be  ‘radical’  processes.  As  demonstrated  by  the  grayed  rows,  most  human 
intervention  is  removed,  which  increases  the  knowledge  in  the  interface  between  the  IT 
systems  and  decreases  the  errors  caused  in  the  submission  of  requests.  The  relative 
comparison  between  the  two  processes  yields  an  increase  in  ROK  and  efficiency  of  63% 
(40.47%  /24.75%=63%). 
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Figure  29.  Radical  KVA  Spreadsheet. 


D.  CONCLUSION 

The  NMCI  account  management  process  has  made  tremendous  progress  since  the 
inception  of  the  NMCI  network.  Flowever,  in  order  for  the  system  to  evolve  fully,  the 
business  rules  should  include  continuous  process  improvement  with  the  actors  (i.e.,  A/D 
CTRs)  in  mind.  The  users  are  an  important  part  of  the  process  and  they  could  provide 
useful  recommendations  for  changes  in  the  process  if  given  the  opportunity.  Creating  a 
forum  or  Community  of  Interest  (COI)  for  them  would  enable  them  to  express  their 
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concerns  and  provide  beneficial  solutions.  This  COI  would  be  in  addition  to  the 
Enterprise  Account  Management  Working  Group  (EAMWG)  and/or  the  EAMWG  should 
include  some  of  the  lower-level  users  in  its  configuration.  The  working  group  must  meet 
often  and  on  a  continual  basis  while  providing  feedback  to  senior  leadership.  This 
ensures  that  addressing  the  NMCI  account  management  issues  become  and  remain  a 
priority  with  flag-level  support. 

Developing  an  integrated  enterprise-level  tool  should  be  of  the  highest  priority. 
The  research  revealed  that  current  stove-piped  systems  such  at  NET,  SR  eForm,  and 
eMarketplace  are  inefficient  and  ineffective  in  their  current  state.  While  many  reasons 
for  their  inefficiency  and  ineffectiveness  could  be  mentioned  in  this  section,  it  is  more 
important  to  note  the  research  showed  these  systems  were  neither  well  developed  nor 
well  deployed,  therefore  contributing  largely  to  the  $35  million  per  year  for  the  last 
several  years  for  additional,  and  perhaps  unnecessary,  accounts.  The  inability  to 
effectively  manage  accounts  has  caused  friction  between  the  Service  Provider  (SP)  and 
the  Service  Recipient  (SR).  This  strain  in  the  partnership,  as  well  as  the  findings  in  this 
research,  has  led  the  SR  (the  EISN  RC)  to  search  for  creative  ways  to  minimize  the 
additional  costs  associated  with  managing  accounts  as  they  have  started  an  initiative 
which  will  cancel  several  thousand  accounts  believed  to  be  in  excess.  This  initiative 
should  force  the  SP  to  develop  or  purchase  an  automated  solution  that  is  capable  of 
performing  accurate  audits  on  the  allocated  accounts.  As  mentioned  in  the  previous 
section,  a  strong  recommendation  is  also  made  to  review  and  detennine  a  viable 
enterprise  IAM  COTS  solution  that  can  be  used  by  the  USN  AC  and  USN  RC.  While 
this  solution  does  not  address  all  functionality  associated  with  NMCI  management,  it 
does  specifically  address  the  issues  concerned  with  account  management.  It  is  believed 
that  the  functionality  built  into  these  solutions  could  reap  immediate  benefits  and 
substantially  decrease  the  $35  million  bleeding  that  the  USN  RC  is  currently 
experiencing. 

Further,  the  research  surveys  revealed  that  many  users  are  not  aware  of  the 

resources  available  to  assist  with  account  management.  One  in  particular  is  the  use  of 

Active  Directory,  and  not  the  GAL,  to  verify  existing  accounts  and  compare  them  with 

NET  and  eMarketplace.  The  majority  are  unaware  how  to  map  their  local  computer  to 
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Active  Directory  in  order  to  view  exactly  which  accounts  are  being  billed  by  the 
contractor.  Instead,  the  GAL’s  email  account  information  is  used,  which  is  downloaded 
to  a  local  resource  (i.e.,  spreadsheet  or  database)  to  complete  their  monthly  validation  and 
reconciliation. 

This  seems  to  indicate  that  the  users  want  to  manage  properly,  but  do  not  know 
how  to  manage  because  they  have  not  been  properly  trained.  This  could  easily  be 
resolved  if  a  web-based  training  curriculum  were  established  to  assist  them  in  learning 
how  to  use  the  currently  available  tools.  Education  and  training  in  this  area  is  critical, 
and  if  not  done,  the  account  management  process  will  continue  to  be  ‘a  challenge’  despite 
other  future  initiatives  (i.e.,  the  incorporation  of  additional  modules  for  NET  or  other 
changes  in  the  IT  systems). 

Lastly,  the  other  recommendations  made  in  the  ‘radical’  process  should  be 
considered  and  researched.  Parts  of  the  solution  already  exist  in  the  existing  legacy 
systems,  but  what  remains  requires  some  modification  to  the  overarching  policy  and 
systems  to  support  integration.  By  analyzing  and  mapping  the  current  processes  and 
using  a  methodology  such  as  KVA  to  measure  the  knowledge  in  each  of  the  sub¬ 
processes,  managers  can  identify  those  areas  not  providing  much  value  to  the  overall 
process  and  recommend  more  effective  solutions. 
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APPENDIX  A.  CONTRACT  LINE  ITEM  (CLIN)  LIST 


CLIN 

Description 

Last  Posted 

000 1AA 

Fixed  Work  Station,  Red 

13-Nov-03 

000 1AB 

Fixed  Work  Station,  White 

13-Nov-03 

0001 AC 

Fixed  Work  Station,  Blue 

13-Nov-03 

0001  AD 

Fixed  Work  Station,  Thin  Client 

4-Aug-03 

000 1AE 

Remote  User  Credit  (Moved  to  CLIN  004105) 

19-Feb-03 

000 1AF 

Fixed  Workstation,  Classified  Thin  Client 

15-Dec-03 

0002AA 

Portable  Seat 

13-Nov-03 

0002AB 

Ultra-Lightweight  Portable  Seat 

13-Nov-03 

0003AA 

Embarkable  Work  Station,  Full  Service 

13-Nov-02 

0003AB 

Embarkable  Work  Station,  Limited  Service 

28-Apr-04 

0004 AA 

Embarkable  Portable  Seat,  Full  Service 

15-Dec-03 

0004 AB 

Embarkable  Portable  Seat,  Limited  Service 

26-Mar-02 

0004AC 

Non-Ruggedized  Deployable  Portable 

13-Nov-03 

0005AA 

Basic  Hybrid  Seat 

30-Mar-04 

0005AB 

Enhanced  Hybrid  Seat 

30-Mar-04 

0005AC 

Reserved 

16- Jan-02 

0005AD 

Personal  Access  Package  -  100%  Concurrent  Use 

30-Mar-04 

0005AE 

Personal  Access  Package  -  30%  Concurrent  Use 

30-Mar-04 

0006 

Additional  Standard  Wall  Plug  Seivice 

21 -May-03 

0006AA 

Additional  Standard  Wall  Plug  Seivice 

21 -May-03 

0006AB 

Unclassified  Wall  Plug  -  Service  Only 

21 -May-03 

0006AC 

Classified  Wall  Plug  -  Service  Only 

21 -May-03 
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CLIN 

Description 

Last  Posted 

0006AD 

Unclassified  Wall  Plug 

30-Mar-04 

0006AE 

Classified  Wall  Plug  -  Inside  a  Controlled  Access  Area 

30-Mar-04 

0006AF 

Classified  Wall  Plug  -  Outside  a  Controlled  Access  Area 

30-Mar-04 

0006AG 

Project  Wall  Plug 

30-Mar-04 

0006AH 

Switch  Port  -  Low  Bandwidth  Service 

22-Sep-03 

0006AJ 

Switch  Port  -  High  Bandwidth  Service 

22-Sep-03 

0006AK 

Sub-Device  IP  Address  Management  Service 

22-Sep-03 

0006AL 

Project  Wall  Plug  Service  (Group  of  8) 

13 -Feb-04 

0006AM 

Project  Wall  Plug  Service  (Group  of  12) 

13 -Feb-04 

0006AN 

Project  Wall  Plug  Service  (Group  of  12) 

13 -Feb-04 

0006AP 

Project  Wall  Plug  Service  (Group  of  12) 

13 -Feb-04 

0007 

High-End  Upgrade  Packages 

N/A 

0007 

For  CLIN  000 1AA  Fixed  Workstation  Red 

13 -Nov-03 

0007 

For  CLIN  0002AA  &  0002AB  Portable 

13-Nov-03 

0007 

For  CLIN  0003AA  Full  Service  Embarkable 

13-Nov-02 

0007 

For  CLIN  0004AA  Full  Service  Embarkable  Portable 

12-Dec-01 

0008AA 

Mission-Critical  Upgrade  Package  -  Single  Connection 

22-Dec-04 

0008AB 

Mission-Critical  Upgrade  Package  -  Dual  Connection 

22-Dec-04 

0009AA 

Classified  Connectivity  Upgrade  Package 

22-Apr-03 

0009AB 

Switchable  Classified  Connectivity  (Thin  Client  Solution) 

22-Oct-03 

0009AC 

Switchable  Classified  Connectivity  (Dual  CPU  Solution) 

26-Mar-02 

0009AD 

Re-Bootable  Classified  Connectivity  Upgrade  Package 

6-Mar-02 

0009AE 

Switchable  Classified  Connectivity  Upgrade  Package  (Dual  CPU  Solution/White) 

26-Mar-02 

0009AF 

Switchable  Classified  Connectivity  Upgrade  Package  (Dual  CPU  Solution/Blue) 

26-Mar-02 
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CLIN 

Description 

Last  Posted 

0009AG 

Switchable  Classified  Connectivity  Upgrade  Package  (Dual  CPU 
Solution/Portable) 

26-Mar-02 

0009AH 

Switchable  Classified  Connectivity  Upgrade  Package  (Dual  CPU  Solution  /  Non- 
Ruggedized  Deployable  Portable) 

24-M-02 

0010AA 

Basic  Voice  Seat 

4-Dec-00 

0010AB 

Business  Voice  Upgrade  Package 

4-Dec-00 

00 10  AC 

Mission-Critical  Voice  Seat  Upgrade  Package 

9 -Apr- 01 

00 10  AD 

Pier  Voice  Line 

4-Dec-00 

0010AE 

Pier  Voice  Trunk 

4-Dec-00 

001  OAF 

Commercial  Voice  Seat 

4-Dec-00 

00 10  AG 

Commercial  Voice  Connectivity 

4-Dec-00 

0011 

Secure  Voice  Seat 

4-Dec-00 

0012 

Mobile  Phone  Seat 

4-Dec-00 

0013 

Personal  Paging  Service  Seat 

24-Jul-02 

0014 

Fixed  Video  Teleconference  Seat 

4-Nov-03 

0015 

Moveable  Video  Teleconference  Seat 

4-Dec-00 

0015AA 

Basic  Moveable  VTC  Seat 

22-May-02 

0015AB 

Fligh-End  Moveable  VTC  Seat 

22-May-02 

00 15  AC 

Mission-Critical  Moveable  VTC  Seat 

4-Dec-00 

00 15  AD 

Premium  Moveable  VTC  Seat 

22-May-02 

0016AA 

Additional  File  Share  Services  -  Unclassified  (10Gb) 

30-Mar-04 

0016AB 

Additional  File  Share  Services  -  Classified  (10Gb) 

30-Mar-04 

0016AC 

Email  Storage  -  Unclassified  (25Mb) 

30-Mar-04 

00 16  AD 

Additional  Email  Storage  -  Classified  (25MB) 

30-Mar-04 

0017 

Internet  Access  for  Mobile  Phone  Seat 

4-Dec-00 
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CLIN 

Description 

Last  Posted 

0018 

Classified  Remote  Access  Service 

26-Mar-02 

0019 

Reserved 

2-Jul-00 

0020 

Data  Seat  Voice  Communications  Upgrade 

9-Apr-01 

0021 

Defense  Messaging  System  Data  Seat  Upgrade 

6-Mar-02 

0022 A  A 

Basic  Desktop  VTC 

1 -Aug-03 

0022AB 

High-End  Desktop  VTC 

1 -Aug-03 

0023 

Optional  User  Capabilities 

25 -Apr-05 

0024 

Additional  Non-Classified  Account 

9-Apr-01 

0025 

Additional  Classified  Account 

9 -Apr- 01 

0026 

Additional  Moves,  Adds,  Changes 

21 -May-03 

0026AA 

Additional  Moves,  Adds,  Changes 

26-Jun-03 

0026AB 

Physical  MAC  Group  of  50 

26-Jun-03 

002 6 AC 

Physical  MAC  -  Group  of  250 

26-Jun-03 

0026AD 

COI  MAC 

26-Jun-03 

0026AE 

Voice  Moves,  Adds,  and  Changes 

22-Sep-03 

002 6 AF 

VTC  Moves,  Adds,  and  Changes 

5-Jan-01 

002 6 AG 

Annual  Administrative  MAC 

21 -May-03 

0026AH 

Annual  Physical  MAC 

21 -May-03 

0026AJ 

Annual  Physical  MAC  (Needing  a  Wall  Plug) 

21 -May-03 

002 6 AK 

Annual  Embarkable  MAC 

21 -May-03 

002 6 AL 

Administrative  MAC  (Single) 

26-Jun-03 

0026AM 

Physical  MAC  (Single) 

26-Jun-03 

002 6 AN 

Embarkable  MAC  (Single) 

26-Jun-03 

0026AP 

Project  MAC  (Single) 

4-Nov-03 
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CLIN 

Description 

Last  Posted 

0026AQ 

Project  MAC  Service 

11 -Mar-04 

002  7AA 

Standard  Low  Bandwidth  Application 

21 -May-03 

002  7 AB 

Standard  Medium  Bandwidth  Application 

21 -May-03 

0027AC 

Standard  High  Bandwidth  Application 

21 -May-03 

002  7AD 

Mission-Critical  Low  Bandwidth  Application 

4-Dec-00 

0027AE 

Mission-Critical  Medium  Bandwidth  Application 

6-Feb-01 

0027AF 

Mission-Critical  High  Bandwidth  Application 

4-Dec-00 

0027AG 

Legacy  Application  Server  Connection 

26-Jun-03 

0028 

Data  Warehousing 

4-Nov-03 

0029 

Legacy  Systems  Support 

4-Nov-03 

0030 

Network  Operations  Display 

16- Jan-02 

0031 

Military  Personnel  Core  Competency  Development  (Sea-Shore  Rotation  and 
Operating  Forces/Supporting  Establishment  Rotations) 

25-Jan-02 

0032 

External  Network  Interface 

4-Nov-03 

0033 

Information  Technology/Knowledge  Management  Retraining  Program 

6-Feb-01 

0034 

Satellite  Terminal  Support 

4-Nov-03 

0036 

OCONUS  Service 

8-Apr-05 

003  8 AA 

Developer  Fixed  Workstation  Upgrade 

22-Dec-04 

003  8 AB 

Developer  Portable  Workstation  Upgrade 

26-Mar-02 

003  8 AC 

S&T  Terminal  Services 

22-Sep-03 

003  8 AD 

S&T  Fast  Ethernet  Wall  Plug 

16- Jan-02 

003  8 AE 

S&T  Wall  Plug  Service  -  Modified  Gigabit  Ethernet  Network  Transport-Lots  of  4 

16- Jan-02 

003  8 AF 

S&T  Wall  Plug  Service  -  Modified  Gigabit  Ethernet  Network  Transport-Lots  of  8 

16- Jan-02 

003  8 AG 

S&T  Wall  Plug  Service  -  Modified  Gigabit  Ethernet  Network  Transport-Lots  of  16 

16- Jan-02 

105 


CLIN 

Description 

Last  Posted 

003  8 AH 

S&T  Network  Transport  -  Other 

4-Nov-03 

4101 

Desktop  Support 

19-Feb-03 

4102 

Desktop  Refresh 

19-Feb-03 

4103 

Desktop  Refresh  With  NMCI  Gold  Disk  Software 

19-Feb-03 

4104 

Assumption  of  Responsibility 

19-Feb-03 

4105 

Remote  User  Credit 

19-Feb-03 

4106 

Remote  User  Credit  (Japan) 

6-Jun-03 

0043 

Asbestos  Material  Abatement 

1 -Aug-03 

0044 

Department  of  Defense  Mentor-Protege  Program  (0044AA  -  0044AF) 

23-Dec-03 

0046 

File  Removal  Service 

19- Jan-05 

0047 

Software  Certification  (0047AA  -  0047AD) 

24-Nov-04 

0048 

Software  Distribution  (0048AA  -  0048AB) 

22-Dec-04 

0049 

Hardware  Certification  and  Installation  (0049AA  -  0049AD) 

22-Dec-04 

0051 

Waterfront  Support  (005 1AA  -  005 1AB) 

27-May-05 

0053 

Premier  Support  (0053AA  -  0053AB) 

27-May-05 
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APPENDIX  B.  NMCI  ACCOUNT  MANAGEMENT  SURVEY 

QUESTIONS 


Navy  Marine  Corps  Intranet  (NMCI) 

Account  Management  Survey  Questions  for  all  Navy  Reserve  Activities  (NRA) 

For  the  purpose  of  this  survey,  Reservists  include  all  Drilling  Reservists  ( DRILLRES ), 
Full  Time  Support  (FTS)  personnel  are  explicitly  separated  from  the  Reservists  category. 

Administrative 

1.  Name  of  your  Navy  Reserve  Activity  (NRA):  (data  entry  field,  30  char)  (REQ) 

2.  NRA  UIC:  (data  entry  field,  10  char)  (REQ) 

3.  Your  Echelon  IV  command:  (REQ) 

(Pull  down  menu): 

i.  REDCOM  Northeast 

ii.  REDCOM  Mid  Atlantic 

iii.  REDCOM  Southeast 

iv.  REDCOM  South 

v.  REDCOM  Southwest 

vi.  REDCOM  Northwest 

vii.  REDCOM  Midwest 

viii.  NAR  Atlanta 

ix.  NAR  Brunswick 

x.  NAR  FT  Worth 

xi.  NAR  Jacksonville 

xii.  NAR  New  Orleans 

xiii.  NAR  Norfolk 

xiv.  NAR  Point  Mugu 

xv.  NAR  San  Diego 

xvi.  NAR  Whidbey  Island 

xvii.  NAR  Willow  Grove 
xviii.  Other 

a.  If  other,  what  is  the  name  of  your  echelon  IV  command?  (Text  Box) 

107 


4.  Date  NRA  cutover  to  NMCI:  (month,  year  drop  down  menu)  (REQ) 

5.  Number  of  Reservists  assigned  to  your  NRA:  (Data  Entry  Field:  5  char)  (REQ) 

6.  Number  of  Full  Time  Support  personnel  assigned  to  your  NRA:  (Data  Entry 
Field:  5  char)  (REQ) 

7.  Do  the  majority  of  the  DRILLRES  drill  on  or  offsite? 

(2  radio  blocks:  “on-site”  or  “off-site”)  (REQ) 

8.  Is  NMCI  management  a  primary  duty  or  collateral  duty?  (2  radio  blocks:  “primary 
duty”  or  “collateral  duty”)  (REQ) 

a.  If  a  collateral  duty,  does  it  warrant  a  full-time  position?  (3  radio  blocks: 
“yes”  or  “no”  or  “not  a  collateral  duty”)  (REQ) 

b.  If  a  primary  duty,  does  it  occupy  sufficient  time  to  be  warranted?  (3  radio 
blocks:  “yes”  or  “no”  or  “not  a  primary  duty”)  (REQ) 

9.  Does  your  command  have  a  standardized  check-in  and  check-out  procedure  (i.e. 
check-in  check-out  sheet)?  (2  radio  blocks:  “yes”  or  “no”)  (REQ) 

a.  If  yes,  is  the  NMCI  account  management  process  linked  with  your 
DRILLRES/FTS  check-in  and  check-out  process?  (2  radio  blocks:  “yes” 
or  “no”) 

b.  How  is  the  check-in  and  check-out  procedure  enforced?  (text  box) 

NMCI  Account  Management 

10.  Do  you  have  a  standardized  procedure  for  NMCI  account  management?  (2  radio 
blocks:  “yes”  or  “no”)  (REQ) 

1 1.  If  you  answered  “yes”  to  #10,  please  explain  in  detail  your  step-by-step  NMCI 
account  management  process  for  the  following  situations: 

a.  Checking  in  a  DRILLRES  new  to  the  Navy  Reserve:  (Data  entry  field, 

250  char) 

b.  DRILLRES/FTS  transferring  to  your  command  from  another  command: 

(Data  entry  field,  250  char) 

c.  A  DRILLRES/FTS  leaving  your  command  and  transferring  to  another 
command:  (Data  entry  field,  250  char) 
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d.  A  DRILLRES/FTS  terminating  service  in  the  Navy  Reserve:  (Data  entry 
field,  250  char) 

e.  DRILLRES  transferring  to  active  duty:  (Data  entry  field,  250  char) 

12.  What  are  the  most  difficult  or  time  consuming  parts  of  the  process?  (Data  entry 
field,  250  char)  (REQ) 

13.  What  automation  tools  are  utilized  by  the  NMCI  account  manager?  (checkboxes: 

“Excel”  and  “Access”  and  “Word”  and  “NET”  and  “NSIPS”  and  “Other”  +  data 
entry  field  to  explain  “other”)  (REQ) 

14.  Prior  to  submitting  a  MAC,  do  you  verify  that  an  NMCI  account  does  not  already 
exist  for  that  individual?  (2  radio  blocks:  “yes”  or  “no”)  (REQ) 

a.  If  yes,  what  is  your  verification  process?  (Data  entry  field,  250  char) 

15.  What  steps  do  you  take  if  the  individual  already  has  an  NMCI  account?  (Data 
entry  field,  250  char)  (REQ) 

16.  How  do  you  ensure  that  every  DRILLRES/FTS  has  only  one  NMCI  account? 

(Data  entry  field,  250  char)  (REQ) 

17.  Do  you  verify  legitimate  multiple  account  requirements?  (2  radio  blocks:  “yes” 
or  “no”)  (REQ) 

a.  If  yes,  please  explain  how  you  verify  legitimate  multiple  account 
requirements  (i.e.  A  contractor  who  also  is  a  DRILLRES)  (Data  entry 

field,  250  char) 

18.  Do  you  submit  your  MAC/ order  request  to  the  next  higher  echelon  (higher  level 
Customer  Technical  Representative  (CTR))  for  approval  prior  to  placing  the  order 
or  MAC?  (radio  blocks:  “yes”  or  “no”)  (REQ) 

19.  Do  you  receive  notification  when  an  account  is  created  or  modified?  (radio 
buttons,  “yes”  or  “no”)  (REQ) 

NMCI  Account  Management  Processing  Time 

20.  On  average,  how  many  times  a  week  does  each  of  these  occur? 

a.  Checking  in  a  DRILLRES  new  to  the  Navy  Reserve:  (REQ) 

b.  DRILLRES/FTS  transferring  to  your  command  from  another  command: 

(REQ) 
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c.  DRILLRES/FTS  leaving  your  command  and  transferring  to  another 
command:  (REQ) 

d.  A  DRILLRES/FTS  terminating  their  service  in  the  Navy  Reserve:  (REQ) 

e.  A  DRILLRES  transferring  to  active  duty:  (REQ) 

(for  each  a,  b,  c,  d,  e,  build  nine  radio  blocks:  “0-10”  or  “1 1-20”  or  “21-30”  or 
“3 1  -40”  or  “4 1  -50”  or  “5 1  -60”  or  “6 1-70”  or  “7 1  -80”  or  “over  80  times”) 

2 1 .  On  average,  how  long  does  each  individual  process  take  (from  the  time  the 
request  is  made  to  the  time  the  action  is  completed)? 

a.  Checking  in  a  DRILLRES  new  to  the  Navy  Reserve:  (REQ) 

b.  DRILLRES/FTS  transferring  to  your  command  from  another  command: 

(REQ) 

c.  DRILLRES/FTS  leaving  your  command  and  transferring  to  another 
command:  (REQ) 

d.  A  DRILLRES/FTS  terminating  their  service  in  the  Navy  Reserve:  (REQ) 

e.  A  DRILLRES  transferring  to  active  duty:  (REQ) 

(for  each  a,  b,  c,  d,  e,  build  nine  radio  blocks:  “half  day”  or  “one  day”  or  “one 
and  a  half  days”  or  “two  days”  or  “three  days”  or  “four  days”  or  “five  days”  or 
“within  a  week”  or  “over  a  week”) 

22.  Do  you  have  a  method  for  managing  accounts  derived  from  seat  purchases  (i.e. 
Two  accounts  for  each  unclassified  seat,  five  accounts  for  each  classified  seat)? 

(radio  blocks:  “yes”  or  “no”)  (REQ) 

a.  If  yes,  please  explain  your  management  process:  (data  entry  field,  250 
char) 

b.  How  do  you  track  the  CLINS  (by  quantity  and  type)  you  have  purchased? 

(data  entry  field,  250  char)  (REQ) 

23.  On  average,  how  many  hours  per  week  do  you  spend  on  account  management? 
(radio  buttons,  “0-5  hours”  or  “6-10  hours”  or  “1 1-15  hours”  or  “16-20  hours”  or 
“21-25  hours”  or  “26-30  hours”  or  “over  30  hours  ”)  (REQ) 

24.  On  average,  how  many  hours  per  month  do  you  spend  on  account  management? 
(radio  buttons:  0-10  hours,  11-20  hours,  21-30  hours,  so  on)  (REQ) 
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25.  If  you  did  not  have  any  automation  tools  at  your  disposal  (Excel,  NMCI 
Enterprise  Tool  (NET),  etc)  and  were  forced  to  manage  NMCI  through  logbooks, 
face-to-face  communication,  and  other  non-automated  means,  how  much  time  do 
you  predict  it  would  take  to  properly  manage  NMCI  accounts?  (REQ) 

a.  Predicted  time  per  month  (time  in  hours):  (radio  buttons  “0-10,  1 1-20,  21- 
30,  31-40,  41-50,  over  50  hours”)  (REQ) 

Command  Questions 

26.  What  outputs  (in  the  form  of  reports,  confirmations,  emails,  messages,  etc)  are 
part  of  your  account  management  process?  Please  provide  input  to  the  following 
table,  following  the  example  provided,  and  list  all  applicable  outputs.  (REQ) 


Output  Product 

Format  Used 

Submitted  To 

Frequency 

NMCI  Update 

Access  Report 

CO,  XO,  OPS 

Monthly 

27.  Do  you  have  access  to  the  NMCI  Enterprise  Tool  (NET)?  (radio  buttons,  “yes”  or 

“no”)  (REQ) 

a.  If  yes,  do  you  use  NET  to  manage  your  NMCI  orders  and  account  data? 

(radio  buttons,  “yes”  or  “no”) 

b.  If  yes,  what  information  are  you  entering  into  NET?  (data  entry  field,  250 
char) 

28.  How  many  hours  do  you  estimate  it  would  take  to  adequately  train  an  individual 
(i.e.  your  relief)  to  perform  account  management?  (radio  buttons:  “0-10  hours”  or 
“11-20  hours”  up  to  “over  80  hours”)  (REQ) 

a.  Of  the  training  time  allowance  indicated  above,  how  much  of  that  time 
would  be  required  to  train  an  individual  to  handle  the  following  tasks: 

i.  Checking  in  a  DRILLRES  new  to  the  Navy  Reserve:  (REQ) 

ii.  DRILLRES/FTS  transferring  to  your  command  from  another 

command.  (REQ) 
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iii.  DRILLRES/FTS  leaving  your  command  and  transferring  to 
another  command:  (REQ) 

iv.  A  DRILLRES/FTS  terminating  their  service  in  the  Navy  Reserve: 

(REQ) 

v.  A  DRILLRES  transferring  to  active  duty:  (REQ) 

29.  Do  you  have  any  recommendations,  concerns  or  complaints  about  NMCI  account 
management  within  your  command?  (data  entry  field,  250  char) 
a.  Outside  your  command?  (data  entry  field:  250  char) 
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APPENDIX  C.  INTEGRATED  WEB-BASED  ENTERPRISE  TOOL 

PROTOTYPE 


The  web-enabled  database  prototype/solution  that  was  created  would  replace 
several  of  the  applications  that  currently  do  not  interface  with  any  of  the  enterprise-level 
systems.  The  To-Be  prototype  was  designed  as  an  interim  solution  to  ease  the  account 
management  challenges  for  the  claimancy  until  the  next  module  of  NET  has  been 
completed.  It  demonstrates  the  type  of  functionality  that  should  be  incorporated  in  a 
more  robust  version  of  the  SR  eForm  or  in  the  next  module  of  NET.  This  prototype  is 
not  fully  functional  and  should  not  be  deployed  in  its  current  state  as  there  are  numerous 
technical  functions,  security  considerations,  and  quality  attributes  that  must  be  added 
before  it  is  equipped  to  handle  the  magnitude  of  data  required  for  an  enterprise  level 
solution. 

Several  assumptions  were  made  when  designing  the  website,  which  are  apparent 
in  its  demonstration,  and  appear  as  follows: 

•  The  prototype  has  no  direct  interface  with  NET 

•  NET  will  continue  to  perform  seat  management  as  it  does  currently.  This 
assumption  was  made  because  NET  currently  appears  to  perform  seat 
management  adequately  and  the  issues  surrounding  seat  management  were 
not  the  focus  of  this  project. 

•  The  data  cleansing  is  complete  or  near  completion.  The  prototype  does 
not  perform  tasks  associated  with  cleaning  up  the  database  from  its  current 
state 

•  The  prototype  will  be  initially  populated  with  data  from  Active  Directory. 
After  the  data  cleansing,  all  accounts  will  be  loaded  into  this  site  before  it 
becomes  fully  functional. 

The  benefits  of  the  functionality  embedded  in  the  prototype  are  tremendous.  Each 
of  the  pages  was  designed  with  the  user  in  mind  and  includes  many  of  the  quality 
attributes  desired  based  on  the  user  surveys.  Additionally,  the  website  was  designed  to 
achieve  efficiency  in  management  at  all  levels,  from  the  lower  level  ACTR  to  the  highest 
level  CTR.  Some  of  the  advantages  are: 
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•  Addresses  rapid  MAC  submissions  with  the  use  of  auto-fdl  and  dropdown 
menus  to  populate  repetitive  data  and  enhance  the  user  interface.  This 
eliminates  the  need  for  the  user  to  type  common  data  manually  for  every 
MAC  submission. 

•  The  site  guides  ACTRs/DCTRs  through  a  standardized  process  for 
completing  any  request.  It  eliminates  the  ambiguity  in  completing  a 
request,  as  the  site  will  automatically  present  the  next  required  step  when 
the  “submit”  action  button  is  selected. 

•  Reduce  duplicate  accounts  (in  error).  The  site  queries  user  names,  lists 
match,  and  display  the  user’s  account  history. 

•  The  site  has  many  embedded  training  links  making  it  a  user-friendly 
environment  where  account  managers  can  easily  learn  the  difficult  NMCI 
tenninology,  business  rules,  and  Active  Directory  mapping. 

•  The  website  will  automatically  submit  requests  to  the  contractor’s  SRM 
Team  to  deliver  and  install  hardware;  to  handle  MAC  requests;  and 
generate  trouble  tickets. 

•  Transparent  linking  of  profiles  to  seats.  Ensures  100%  utilization  of  free 
accounts  by  attaching  them  automatically  to  seats.  This  is  performed 
without  any  additional  action  required  by  the  user. 

•  The  DCTR  will  be  able  to  perfonn  all  the  actions  of  an  ACTR  through 
access  to  their  data  repository. 

•  The  DCTR  view  shows  a  hierarchy  of  subordinate  commands. 

•  Security  authentication  and  write  access  based  on  the  login  ID  has  been 
implemented. 

•  Some  fonn  validation  exists  in  the  site  but  does  not  incorporate  it  into 
every  required  page.  Some  fields  accept  for  information  that  is  unique  in 
the  business  rules  (i.e.,  asset  ID,  seat  ID  etc.) 

•  This  prototype  is  also  devoid  of  mandatory  functionality  to  ensure 
integrity  of  the  system  and  interface  with  enterprise-level  systems  (i.e., 
NET). 

The  recommended/required  outstanding  items  that  should  be  added  to  the  system 

are: 

•  The  site  does  not  include  bulk  requests  submissions  although  it  is  certainly 
recommended. 

•  It  does  not  interact  with  any  other  database  and  is  only  as  good  as  the  data 
that  currently  exist  in  the  database.  An  interface  should  be  built  that 
would  provide  an  interface  to  NET  and  perhaps  Active  Directory. 
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A.  DATABASE  SCHEMA 


G  Microsoft  Access  -  [Relationships] 


-Xj  File  Edit  View  Relationships  Tools  Window  Help 

J  ^  A  n  "  °gj!X  J  J’ 


Type  a  question  fc 


Description 

AccountStatus 

Type 

SiteCode 

Status 

eFormllserGroup 

password 

Rank 


AccowtStatusNu 

AccountStatus 

AccountStatAbb 


LogOnName 

:  UserNum_FK 
CmdUIC 
CmdBase 
CmdAddress 
CmdPhone 
CmdEmail 
CmdStreetAddress 
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Currently  the  NMCI  management  process  includes  approximately  five  enterprise- 
level  IT  systems  and  a  myriad  of  applications  used  for  local  tracking  and  management.  The 
primary  enterprise-level  systems  are: 

NMCI  Enteiprise  Tool  (NET)  with  a  primary  function  to  manage  seat  data  and 
for  build-outs  3  of  new  commands. 

Electronic  Marketplace  (eMarketplace)  for  billing  and  invoicing. 

Service  Request  Electronic  Form  (SREform)  for  submission  of  hardware, 
software,  and  account  Move- Add-Changes  (MAC). 

MS  Outlook  Global  Address  List  (GAL)  to  verify  the  existence  of  an  account. 

MS  Active  Directory  to  verify  account  totals  for  billing  purposes. 

Each  of  the  various  systems  currently  used  maintains  data  that  is  critical  for  NMCI 
management.  However,  no  capability  exists  to  automatically  exchange  data  between  them 
for  system  updating  purposes,  and  no  synchronization  exist  between  them  for  data  integrity. 
The  lack  of  a  fully  integrated  system  requires  the  technical  representatives  to  retrieve  data,  in 
some  cases  redundant  data,  from  each  to  perfoim  daily  routine  tasks. 

Budget  cuts  have  minimized  funding  dollars  required  to  effectively  train  personnel  on 
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a  decrease  in  service  levels  in  other  areas  of  responsibility.  Many  of  the  Echelon4  V  technical 
representatives  perform  the  NMCI  management  responsibility  as  a  collateral  (or  secondary) 
job  assignment.  The  current  process  has  become  extremely  labor-intensive  and,  in  some 
instances,  requires  other  command  personnel  to  perform  functional  tasks  that  would  have 
otherwise  been  performed  by  the  technical  representative  as  a  primary  job  assignment.  This 
shift  in  responsibility  has  placed  an  unnecessary  burden  on  many  commands  that  are  already 
short-staffed.  A  solution  is  required  to  improve  this  process  and  provide  the  necessary 
feedback  and  reports  for  verification  and  accuracy  of  data  submitted  by  the  contractor. 

The  current  process,  tools,  and  business  rules  have  caused  the  USNR  to  accumulate 
an  enormous  amount  of  chargeable  accounts,  resulting  in  approximately  $30  million  in 
additional  costs  for  user  accounts.  The  elimination  of  excess  accounts  from  the  Active 
Directory  has  been  a  daunting  task  partially  because  technical  representatives  and  users  are 
having  difficulty  determining  which  accounts  are  excess  and  which  are  a  justifiable  need. 
Excess  accounts  can  be  categorized  as  duplicate  accounts  existing  in  the  Active  Directory  that 
are  not  required.  These  accounts  result  in  unnecessary  and  substantial  charges  to  the  USNR. 
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NMCI  ACTR  Seat  and  Asset  Management  Tool:  This  tool  shall  be  available  to  all  ACTRs 
to  perform  the  following  tasks: 


■  Place  an  order  for  a  new  seat  (i.e.  portable  or  desktop  computer,  peripheral  that  is  not 

assigned  to  a  computer)  or  new  hardware  (peripheral  devices  such  as  a  printer,  scanner  or 
PDA,  etc.).  The  tool  shall  allow  entry  of  all  the  contractor  required  data  fields  and  the 
request  should  automatically  be  submitted  to  the  authorized  submitter  (DCTR)  for 
approval  prior  to  forwarding  to  the  contractor  for  final  action. 

■  View  and  edit  seat  data  once  a  seat  has  been  entered  into  the  tool  and  installed.  This 

allows  the  authorized  initiator  (ACTR)  to  quickly  recall  and  administratively  make 
modifications  to  information  that  may  have  been  entered  about  a  specific  seat.  Any 
administrative  modification  to  seat  or  account  data  does  not  require  the  approval  of  the 
DCTR  or  action  by  the  contractor,  but  is  simply  updating  the  current  information  that  is 
within  the  database. 

■  View  and  Edit  hardware  and  peripherals  that  have  been  entered  into  the  tool  and  installed. 

This  shall  also  allow  the  ACTR  to  administratively  make  modifications  to  information 
that  may  have  been  entered  about  a  specific  piece  of  hardware  or  peripheral 

■  Request  an  upgrade  to  an  existing  seat  will  allow  the  ACTR  to  submit  a  request  for 

modification  to  a  seat’s  current  configuration.  This  change  may  require  additional  costs 
therefore  the  tool  should  be  sophisticated  enough  to  forward  any  change/upgrade  requests 
to  the  authorized  submitter  or  DCTR  prior  to  submission  to  the  contractor. 

■  Request  a  seat  to  be  relocated  to  another  location.  This  shall  enable  an  ACTR  to  use 

automation  to  recall  all  the  seats  and  specify  which  seats  will  need  to  be  moved  and  to 
provide  their  desired  location.  This  is  a  billable  action  therefore  the  request  for 
equipment  relocation  should  be  automatically  submitted  to  the  DCTR  for  approval  prior 
to  submission  to  the  contractor. 

■  A  view  of  all  invoiced  items  with  the  seat  identification  number,  any  additional  hardware 

that  is  attached  to  the  seat,  itemized  costs  for  each,  and  the  accumulated  dollar  total  for 
monthly  invoice  validation. 

■  The  ability  to  use  automation  to  submit  a  request  to  return  any  seat  to  the  contractor  that  is 

no  longer  required.  The  ACTR  should  have  to  perform  minimal  data  entry  for  this  action 
to  occur  by  including  a  consolidated  list  of  all  seats,  the  ability  to  select  the  seat  to  return, 
pre-populated  text  entry  fields  that  include  the  seat  information,  and  an  option  to  submit 
selected  seat  for  return. 

■  The  ability  to  administratively  add  any  seat  and  the  associated  hardware  peripherals  that 
already  exist  at  the  command  but  is  not  already  listed  in  the  tool.  This  is  an  important 
feature  for  the  organizations  that  have  already  cutover  to  NMCI  and  their  initial  order 
was  not  entered  in  the  tool.  The  action  shall  be  performed  by  the  ACTR  and  no 
forwarding  requirement  to  the  DCTR  or  contractor  exists. 

NMCI  Account  Management  Tool:  This  tool  shall  be  available  to  all  ACTRs  to  perform 
the  following  tasks: 

■  The  capability  to  in-process  a  new  user  or  out-process  and  existing  user.  In-processing 

shall  include  the  ability  to  automatically  check  the  system  to  see  if  a  user’s  name  exists  in 
the  system.  If  one  exists,  the  system  shall  return  all  instances  of  that  name,  and  the 
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account  history,  for  verification  of  possible  accounts  that  may  have  been  previously 
assigned  to  the  user  that  is  in-processing.  The  account  information  of  users  that  are  out- 
processing  shall  be  transferred  from  the  losing  ACTRto  the  gaining  command’s  ACTR’s 
inbox  of  the  tool  for  acceptance. 

■  Newly-created  accounts  shall  be  automatically  assigned  by  the  system  to  a  seat  without 

any  additional  intervention  required  by  the  ACTR.  Once  the  account  totals  have 
exceeded  the  total  accounts  that  accompany  the  seats,  the  tool  shall  automatically  assign 
these  accounts  to  a  chargeable  MAC  (called  a  CLIN  0024). 

■  The  ability  to  view  all  accounts  that  are  associated  with  the  ACTR's  command.  This 

information  shall  mirror  the  information  that  exists  in  the  NMCI  Active  Directory. 
Separation  between  the  accounts  that  are  billable  and  the  non-billable  accounts  shall  be 
made  by  listing  each  category  separately  and  providing  ght  e  totals  for  each. 

■  To  automatically  submit  a  request  for  a  password  to  be  reset. 

NMCI  DCTR  Seat  and  Asset  Management  Tool:  This  tool  shall  be  available  to  all 
DCTRs  to  perform  the  following  tasks: 


■  As  the  authorized  submitter,  the  DCTR  is  required  to  approve  any  MAC  requests  before 

they  are  forwarded  to  the  contractor’s  Service  Request  Management  (SRM)  team.  The 
DCTR’s  web-based  view  shall  include  a  webpage  that  contains  an  inbox  of  requests.  The 
inbox  shall  include  all  requests  forwarded  from  the  lower-level  ACTR’s  from  the  Naval 
Reserve  Activities  (NRA)  that  are  pending  review  and  approval. 

■  The  DCTR  tool  shall  forward  any  requests  that  are  approved  to  the  contractor  SRM  team 

supervisor  web  tool  for  distribution  between  the  contractor  teams. 

■  The  DCTR  tool  shall  generate  and  submit  requests  in  the  absence  of  an  ACTR. 

NMCI  RESFOR  Management  Tool:  This  tool  shall  be  available  to  all  primary  CTRs  to 
perform  the  following  tasks: 

■  Review  all  account  and  seat  accumulated  totals  submitted  by  all  technical  representatives 

within  the  RESFOR  claimancy.  The  tool  shall  include  summary  data  for  the  total  for 
each  account  status  (billable,  non-billable,  used  “free”  accounts,  unused  “free”  accounts, 
CLIN  0024’s  required),  total  seats  installed,  and  total  seats  pending  installation.  Total 
dollar  amounts  shall  be  automatically  calculated  for  quick  reference  against  the 
eMarketplace  totals.  CLIN  0024’s  totals  should  be  calculated  in  summary  of  all 
accumulated  for  quick  reference. 

NMCI  Contractor  Management  Tool:  This  tool  shall  be  available  to  the  supervisors  of  the 
SRM  team  to  perform  the  following  tasks: 

Supervisor: 

■  The  Supervisor  has  overall  management  responsibility  for  all  MACs  submitted  by  the 

authorized  submitter.  Subsequently,  the  supervisor  shall  have  sole  authority  to  view 
accepted  MACs  and  assign  an  SRM  team  that  will  be  responsible  for  servicing  the  MAC 
requests. 
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substantial  losses. 

Application  Users:  Primary  users  of  the  system  and  their  associated  hierarchy  are  listed  in 
the  graph  below.  Users  will  be  granted  access  rights  to  the  system  commensurate  with  their 
assigned  billet  (ie.  ACTR,  DCTR,  RESFOR).  A  user  assigned  a  RESFOR  account  is  an 
Echelon  III  user  and  will  therefore  have  privileges  to  view  all  data  within  the  system.  A  user 
assigned  a  DCTR  account  is  an  Echelon  IV  user.  Echelon  IV  users  are  assigned  authority 
over  a  specific  region  (i.e.  Northeast,  Southwest)  and  will  have  authority  to  view  all  data 
within  their  region.  ACTR  accounts  are  typically  assigned  at  the  Echelon  V  level.  These 
accounts  are  command  accounts  and  they  have  authority  over  users  within  their  command.  A 
detailed  summary  of  user  functionality  is  included  in  section  2.3  of  this  document. 
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User  Authentication:  All  users  will  be  uniquely  identified  by  use  of  a  registered  user  id  and 
secret  password.  Group  or  shared  ids  will  not  be  used.  Passwords  will  meet  the  following 
usage,  construction  and  change  requirements: 

The  password  will  not  be  the  same  as  the  user  id 
Passwords  will  never  be  displayed  on  the  screen 

Passwords  will  be  a  minimum  of  eight  (8)  characters  and  consist  of  mixed  alphabetic  and 
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Project  Trade-ofT  Matrix 


F  irn  ct  ion  al  F  eatur  e  s 

Resources 

(Cost) 

Schedule 

Inflexible 

Flexible 

ACTR  Features 

3.1.1 

3.2.2 

3.1.3 

3.1.4 

3.1.5 

3.1.6 

3.1.7 

3.1. S 

3.1.9 

3.1.10 
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Project  T  rade-off  Matrix 


DCTR  Functional  Features 

Resources 

(Cost) 

Schedule 

Inflexible 

Flexible 

3.2.1 

3.2.2 

3.2.3 

3.2.4 

3.2.5 

3.2.6 

3.2.7 

3.2.2 

Project  T  rade-off  Matrix 
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4.1  Screens 


4.1 .1 .1  In-Process  new  users  “Search  Accounts  for  Profile” 


l  Liiisaj 

O--  v 

TV";  7   , 

■  Iff!  2. 

zlQ* 

Service  Request  eForm 

«... 

\«g 

-  - -  '  'iJ 

Search  Accounts  for  Profile 


JAii*  L-**» 


Erto  luror  et»th  u  t  iff «ri  o«  UMtcy  <*  G 


AccetBU  To  Sunk  I** 


Description 

This  form  allows  the  ACTR  to  enter  the  name  data  of  a  prospective  new 
user  as  it  appears  on  a  government-issued  ID  card.  The  purpose  of  this  is 
to  check  for  an  existing  account  to  prevent  the  creation  of  a  redundant 
account 

Security  Group 

ACTR.  DCTR 

Data 

Last  name,  First  name,  and  Middle  initial  are  entered  in  the  corresponding 
form  boxes  as  they  appear  on  the  prospective  users  ID  Card. 

Actions 

The  "Clear"  button  allows  form  to  be  wiped  clean  in  case  of  an  error.  The 
“Submit"  button  processes  the  data  in  a  search  function  to  check  for 
existing  accounts  that  match  the  input  name.  All  accounts  or  specific 
types  of  accounts  may  be  searched  by  using  the  “Accounts  To  Search” 
drop  down  menu. 
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4.1.1 .2  In-Process  new  users  “Search  Results" 


IO--Q- 


~~5  •  C  5>t»» 


Service  Request  eForm 


\mcj 


Jtt, 


ml*}"} 
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"Ho 


Umx*.  Oratf  h-r  E  LOGO*  ID  thru  omtt,  MAC  revest  ftUaa  Mo*fy  Kt'mmrt 

create  raw  raorm? 


t  J|e '  viitmt   #1w 


Jut—*-*  \n* 


»  »  I  «r  *33^4084  »«« ■ 


Description 

The  search  results  screen  displays  accounts  that  match  the  name  entered 
in  the  “Search  Profiles”  page.  The  results  may  or  may  not  be  a  correct 
match  for  the  prospective  new  users  due  to  some  users  having  names  in 
common.  To  determine  if  the  prospective  new  user  is  a  match  to  one  of 
the  accounts  the  “History"  link  will  display  the  MAC  history  for  the  account 
in  question  allowing  a  user  to  determine  if  the  account  matches  previous 
duty  stations  and  time  frames. 

Security  Group 

ACTR,  DCTR 

Data 

Data  on  this  page  is  derived  from  a  query  on  the  input  user  name  from  the 
“Search  Profiles”  paqe. 

Actions 

Profiles  that  appear  on  this  page  can  be  checked  for  a  match  to  the 
prospective  new  user,  link  to  update  new  information  if  a  match  is 
established,  or  link  to  create  a  new  user  profile  if  required. 
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Btagafl  Baton 


41 .1 .3  Update  User  Profile 
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Description 

Used  to  update  user  profile  information 

Security  Group 

ACTR  DCTR 

Data 

The  data  displayed  initially  on  this  screen  o  the  nlormabon  currently  In  the 
user  profile  table  for  the  user  in  question  Data  for  the  “UtC"  drop  down 
menu  is  provided  from  the  “Activities'  table  Data  for  the  “Typo”  drop  down 
kst  is  is  hard  coded  in  the  webpage 

Actions 

Any  data  on  the  page  can  be  modrfiod  and  Submitted  update  tho  user 
profilo  tablo  A  “Clear  Form*  button  has  been  provided  and  can  bo  usod  to 
clear  all  data  or  tho  screen  before  updating 
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4.1.1 .4  User  MAC  History 


Description 

This  page  displays  MAC  history  from  the  MAC  Table  to  assist  in  te 
determination  of  an  account's  ownership. 

Security  Group 

ACTR.  DCTR 

Data 

Data  on  this  page  comes  from  stored  data  in  the  MAC  table. 

Actions 

None,  Data  is  only  viewable. 

4.1 .1 .5  Add  New  User  Profile 

f*  W  —  MS  H* 

o-  •  .>  ■:  =:*i  ,  ™ 

-  .0. 

3fle. 
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Description 

This  screen  is  used  for  the  input  of  new  user  data. 

Security  Group 

ACTR,  DCTR 

Data 

UIC  field  data  comes  from  the  Activities  table  and  is  default  set  to  the  UIC 
of  the  ACTR  entering  the  data  for  the  new  users  however,  it  may  be 
changed  to  any  UIC  in  the  database. 

Actions 

Form  fields  are  completed  as  required  and  are  submitted  to  enter  data  into 
a  new  user  profile  and  proceed  to  the  creation  of  a  “New  User”  MAC 

request. 

4.1.1 .6  New  User  MAC 


e  •  .  •  .a _ _ 

|e<s<tl  3 •  e  bm.i—  t— <  Bj«—  * 
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Description 

New  users  MAC  request  to  be  submitted  through  the  chain  of  approval  for 
activation. 

Security  Group 

ACTR,  DCTR 

Data 

New  User  data  comes  from  the  user  profile  table.  All  default  command 
data  comes  from  the  activities  table. 

Actions 

Complete  all  fields  as  required  and  submit  for  approval. 

4.1.1 .7  Accounts  within  a  specific  ACTR’s  UIC 
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4.1 .1.8  Account  Detail* 


Description 

Details  on  an  indrvidual  account. 

Security  Group 

ACTR  DCTR 

Data 

Data  I*  from  the  user  proMe  table 

Action* 

User  profile  tab*o  data  can  bo  vwwod  and  thero  is  an  option  to  react  the 
user  s  pa^swor  d  with  the  ’Password  Reset*  tx4ton 

4.1 .2.1  Logon 


O  ■  O  i  I  <*.  /  <r  €  •  «  „  *  «■—  ■  «—  «—  •—  ■■■'  ■ 


Description 

Enables  the  user  to  logon 

Security  Group 

All 

Data 

logOnMame,  password 

Actions 

Redirects  user  to  home  page  based  on  oFormUso-rGroup 
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4.1. 2.2  CookieWriter.asp 


Description 

Writes  cookies  based  on  the  login.  Cookies  for  U  1C,  Log  On  Name, 
DisplayName  and  TFMod#  are  written  to  the  users  computer 

Security  Group 

User,  ACTR,  DCTR,  RESFOR 

Data 

Data  is  pulled  from  TbIUserProfile  based  on  LogOnName 

Actions 

Automatically  loaded  and  redirects  to  home  page  based  on  usergroup 

4. 1.2. 3  ACTR  Home 


E*  l*  »■»  I"*  I 


Service  Request  eForm 


mmsm 


NMCI 


JQL 


ACTR  TOOLBOX 


UNIT  STATISTICS: 

Choore  a  number  below  to 


Vkw  Atttvc  Ac-.vuutl 
fitqmitpMfyyrd.rtW  Hew  to  ice  which  kcoop 
gmthMACliuiea  Wha  |i.a  Ut.pFtoa^v 


in  Tout  Agree  Dttmn 


Or4cr.4MivTiJf4wpt.KJi  f  lit  Data 

KC4MA  to  enitn&itP  ViewfLdfl  Hardware'  J'ctKhenJj 


Description 

List  links  to  all  of  the  functions  that  an  ACTR  needs  to  use.  Has  a  unit 
statistics  table  to  display  totals  for  accounts,  seats,  billable,  non-billable 
and  all  of  the  pending  MACs 

Security  Group 

ACTR,  DCTR 

Data 

All  count  functions  pertain  to  the  UIC  from  the  cookie.  Billable  Accounts  or 
seat  are  not  pending,  deleted  or  disabled.  MACs  counted  in  pending  or 
returned  status 

Actions 

Count  functions,  read  cookies,  Display  actions  performed  when  arrived  to 
from  a  previous  page. 
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4.1. 2.4  Order  a  hardware  seat 


E*.  I*  vj»  l«*  o* 


Description 

To  be  able  to  put  in  the  CLINs,  options,  locations  and  POC  for  installation 
of  new  CLIN 

Security  Group 

ACTR,  DCTR 

Data 

All  pre-filled  fields  are  initially  set  to  the  default  data  found  in  the 

UserProfile  table  joined  with  the  Activities  table  for  the  ACTR/DCTR  who 
has  logged  in.  Drop  down  menus  comefrom  thethree  CLIN_tables  and 
the  Command  Table. 

Actions 

Submit  button  posts  the  form  to  the  Order  Review  page 
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4. 1.2.5  Order  Review 


H  http://ni.170.176.69  NMC.I  Sorvlco  Roquo*t  and  Account  Mariaftomenl  Tool*  Microsoft  Internet  Ixplorer 
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0 

Service  Request  eForm 

Seat  Order  Review 

Meet  Change  (hit  Order  to  edit  f  Jii»  r*gu*jf. 

Select  Order  Thit  Seat  to  place  the  order  with  NMCI. 

|  Change  this  Order  | 

Seat: 

Asset  Location: 

Justification: 

Seat  CLIN 

0001M 

Adikess 

327  Muilin  St 

Required  for  new  sailor 

Option  CLIN 

Non* 

Bate 

NPC  WATERTOWJ 

SubOpsooCLIN 

Non* 

C*y 

Wat*  flown 

Classification 

umlar.tufiitd 

State 

NY 

Bdimg  me 

61851 

ZIP  Code 

1  (bat-024/ 

Task  Order  Mod  1 

P  ial'fcriy.  * 

55 

Floor 

2 

Room  Number 

12 

La«  Name  twreon 

Cubicle 

A 

Fast  Name  t<cfl 

Network  Jack 

55521 2A 

Ranfc/Rate  Na 

Fh-ww  OJt  555  I0W 

Email  A'i'JrcfS  »<ol1t>*n»on®ri*wmll 


|  Submit  Thu  Ordar  | 


Description 

This  page  allows  the  user  to  preview  their  selections  before  they  submit  a 
request. 

Security  Group 

ACTR,  DCTR 

Data 

All  fields  come  from  submitted  form  on  seat_order  page  Hidden  fields 
include  the  date  submitted. 

Actions 

Submit  button  inserts  the  row  into  the  Seat  table  and  extracts  the 
autonumber  for  the  seat  row,  This  number  becomes  a  session  variable 
identifying  the  seatNumber  The  page  also  creates  session  variable  for 

POC  name,  phone  and  email  because  they  may  be  different  from  the 

ACTR.  The  paqe  redirects  to  the  SeatProcessor  page. 

4.1. 26  SeatProcessor.asp 

Screan  displays  only:  Processing  your  request.  Plaaaa  Standby. 


Description 

Adds  a  row  to  the  MAC  table  to  begin  the  request  for  a  new  seat. 

Security  Group 

ACTR.  DCTR 

Data 

SeatNum  is  derived  from  session  variable.  POC  information  comes  from 
the  session  variables  All  other  data  is  read  from  the  Seat  table  and 
written  to  the  MAC  table.  The  MAC  table  can  store  multiple  actions  on  the 
same  seat  which  may  be  at  different  locations 

Actions 

Seat  Order  data  is  written  to  the  MAC  table 
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4.1. 2.7  Seat_Review 
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4.1 .2.8  Seat  Selection 

Service  Request  eForm 

Select  a  Seat  for  UIC-  61851 


NMCI 


This  page  shows  a  li;.t  of  /ho  installed  Stoats  in  your  command.  S 'nhrct  a  scat  to  send  a  hardware  u/orltordor  to  SDS. 
To  administratively  edit  a  seat  without  submitting  a  work  order,  click  here. 

Select  a  Seat  ZD  to  request  a  sub-option  upgrade  lor  that  seat. 
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4/1//2002 

4n/«oo; 

2002801 0 

NK  NMCB  2/  UhT  1 721 

|3 

C038AC 

0008W 

0020 

10/0/2000 

10/6/2006 

2/083010 

NK  NAVHUSK  PORISMUUIH  Uhl  N 

|; 

U004AB 

UUUBAB 

0014 

2/28/2004 

2/28/2008 

2820/028 

NK  MOfiASCONTQRP  021 6 

[2 

0001 AC 

OOOOAC 

0011 

2///20O2 

2///200/ 

28/8/480 

4 

0001AT 

U008AH 

0024 

12/4/2002 

12/4/200/ 

28280333 

NK  COMNAVKhO  MIULAN1  UhT  A 

(9 

0003AA 

OOOOAh 

0020 

3/6/2004 

3/6/2009 

28/118/2 

NK  NMCB  2/ UhT  1/2/ 

|i 

0004AB 

UUUBAB 

0010 

10/8/2002 

1 0/8/200/ 

3U033108 

NKVTU0218 

Is 

OOOOAC 

000UAT- 

001/ 

8n  8/2004 

8/18/2008 

310182/8 

NK  NMCB  2/ UhT  1/2/ 

|io 

OOOIAA 

001 OAh 

0018 

0/3/2000 

6/3/2006 

33211814 

NRVTU  0218 

|s 

0004AA 

OUOBAA 

0023 

1/2  S/2002 

1/26/200/ 

34002383 

NK  NAVHU3P  PORISMUUIH  Uhl  N 

[2 

U038AB 

OOU8AB 

0028 

3/4/2001 

3/4/2006 

30182/21 

NK  COMNAVKhU  MIULANT  UhT  A 

|3 

0038AC  000/ 

0014 

8/1 3/2000 

8/1 3/2006 

4 


Description 

Allows  the  user  to  select  a  seat  to  upgrade,  add  hardware  to.  delete  or 
move.  Seats  in  any  status  other  than  installed  cannot  be  selected  i.e.  if  a 
seat  is  not  installed,  you  shouldn't  be  able  to  request  that  it  be  moved  or 
deleted. 

Security  Group 

ACTR,  DCTR 

Data 

Data  come  from  the  Seat  Table. 

Actions 

Columns  can  be  sorted  to  easily  find  a  Seat.  The  page  displays  a  different 
header  base  on  which  function  you  are  selecting  a  seat  to  perform.  The 
seat  ID  creates  a  querystring  SeatNumber  which  is  retrieved  by  the 
subsequent  page. 
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4.1. 2.9  Seat  Upgrade 


!>  I*  S*~  <*«•*  la*  O'O 

’  •  !«]t«i>//iJi .UD.ii».tWNsaM<cUM«  «>» 


•it  e 


0  0 


■  <  ja 

- 


Service  Request  eForm 


NMl'l 


Request  tor  Seat  Upgrade  or  Change 

Jn  ft |«  dropdown  nwntn  to  rtanoa  f 
CJk*  'Submit  Mom  Ortho*  to  xmit  a  t 

|  Rovn-c5ep'5ei?aon  | 

Seat  Selected: 

Seat  CUN 


cunantcuN  oomw _ 

0003AB  Limned  Series  Embarkable  & 

Cuns.it  opaon  OOOMH 

M08AM  DoKhabtt  na-i-dbrd  CaimulrvUy  UpqrodO  •  Duel  CPU  Solution  ■  NurrAm  |  i  ■  : 


Current  Location: 

A Mnu  327  kilim  St 


NR  WWHOSP  PORTSMOUTH  OET  N 


NMCISaatlD  «M7SWi 


Same  Start  Dale  ||U»2000 
Senvce  End  Date  1 117/2005 
DIC  61851 

TFMod*  rt)OI5 

POC  For  Workorder: 


POO 

Phot*  831  555  ISM 


. 


icon  ban  jon@n*vy  ma 


Description 


Requesting  an  upgrade  or  change  to  an  existing  seat. 


Security  Group 


ACTR,  DCTR 


Data 


Fields  come  from  the  Seat  Table.  POC  comes  from  a  join  between  the 
MAC  table  and  the  user  profile  table. 


Actions 


Submit  button  writes  a  new  record  in  the  MAC  table  with  a  MAC  Status  of 
pending.  Redirect  to  the  ACTR  Home  page  with  a  querystring  to  show 
that  a  seat  has  been  changed. _ 
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4.1.2.10  Request  Seat  Move 


O-  O 


ft  -it  ©  :  '•  «  •i- 


0  0 


nja 

-  H  = 


Request  for  Seat  Move 


Seat  Selected: 

SutCUN  'ocowa 

Option  CUN  M1M 

SiAOpnonCUN  0017 
NMCTSejlID  1*121)00 

Service  Start  Date  ''202000 
Senvce  End  Date  'iJIWOOS 


Current  Location: 


ZIP  Code  13601-0247 

Buldn*# 


DIC 


61851 


Destination  Location: 


POC  For  Current  Location: 


32?  Mullm  Si 

up' ;  wa  tmu  i.'.'i 


ItaK  i  uTmon  M—MiO  INRCWemtoml 

Emad  rt, 

,  icon  bent oeSPiavy  mil 


POC  For  Destination  Location: 

Us*  Nxnr  bomon  -.<rjeMMI(tJRC  Walmliiwn) 
Phone  H  31  W  1B04 


ZIP  Cede 
Building  d 
Fleet 

Room  Number 
Cuticle 

Network  Jeck 


Identdiet  t  workspace  in  <  room 

Ok  >  unique  letter  for  eneh  workspace  when  thu  reel  will  be  mulled 

OpDonal  (t known)  Pre -easting  jsck  where  the  computer  will  be  c  cmucttd  to  the  network 

Jade  numbers  are  located  on  a  label  by  the  jack 


Description 

Request  data  nec.  To  physically  move  a  seat  from  one  place  to  another. 

Securitv  Group 

ACTR,  DCTR 

Data 

Initial  data  in  the  Fields  comes  from  the  TbISeat  row  selected  from  the 
seat  select  page  and  passed  as  a  querystring.  Also  by  the  default  data 
join  of  the  Activities  and  UserProfile  table  based  on  the  user  LogOnName. 

Actions 

MAC  is  written  to  the  MAC  table  with  date  submitted,  pending  status  and 
“Request  Seat  Move"  in  details. 
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4.1.2.11  Seat  Turn-in 


'>  i*  *-  '»•—  i—i>»  ^ 

mr...  _  _  _ *.Q  & 


Service  Request  eForm  ^ 


Request  tor  Seat  Turn-in 


OwngirPCiCopttomatiMKmaary. 

Ctkt  'Submit  Tun-in  Rtquou  *  re  rend  a  bilhhl*  wo rtordor  to  NMa/ChS, 


|  Return  to  Seat  Selection  | 

Seat  Selected: 

Current  Location: 

Seel  CUN  0009AA 

Adieu  5095  B. no.  no 

Option  CUN  OOtOAf 

Rase  NR  NSA  BAHRAIN  OCT  0 

SubOpwruN  udu 

City  uiveou 

hmci  Sen  id  utiiut 

State  »r 

CUi«6canon  untl»n#*d 

ZIP  Code  09119-4119 

Srmct  Sun  free  VI  7)2000 

Biding# 

Semite  Hn<l  Dale  VI  f/2009 

Flooe  2 

me  »Nit 

Room  Humber  " 

IT  Mod#  root! 

Cubtch  C 

POC  For  Workorder: 

Lut  Name  Ctort.  Date  WBUt 

Phone  «?1KSltllM 

Hnuol  Adieu  |JqitclBilt9iteyii# _ ] 

1  Submit  Turmn  Request  1 

Description 

Allows  the  user  to  turn  in  a  seat. 

Security  Group 

ACTR,  DCTR 

Data 

All  field  come  from  the  seat  table.  POC  data  defaults  to  a  join  between 
Activities  and  UserProfile  on  LogOnName  and  UIC. 

Actions 

Submit  button  writes  a  row  to  the  MAC  table  with  hidden  fields  specifying 
turn-in  in  MAC  Details,  and  date  submitted. 
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4.1.2.12  Seat  Details  for  pending  seat 


u'jd 


»»»  O’O  3  ^  ft  /- tr  6  j  3  0  9 


service  Request  eForm  ®“ 

User:  actr.2 
UIC:  61845 

Seat  Details  for  Pending  Seat 

|  Aalum  Ip  Swot  Review  ] 

MACfo'Seal  is  eurrmtly  in  Worlungsnof  O/s/joo 5. 

Seat  Ordered:  Delivery  Location: 


Seat  CUN  0M1M 

Option  CLIN  Non* 

SubOpUouCUN  Non* 

NMCI  Seal  ID 

Clnjsficalien  uwlaoutwl 

StrvKi  Suit  Date 

Smvre  End  Date 

TOC  618*4 

IT  Mod# 

Addrer«  SlOPi-at*. 

But  NASPMdMaiOw 

Stale  Hi 

ZIP  Code  OMU  »7«1 

BuMng#  1 

Floor  1 

Room  Number  1 

Cubicle  « 

•  "'i"* 

Description 

This  allows  user  to  view,  but  not  edit,  any  attributes  of  a  seat  in  Pending 
status.  It  is  used  to  verity  requested  edits,  new  orders,  requests  for  moves 
ortum-ins. 

Security  Group 

ACTR,  DCTR 

Data 

All  fields  come  from  the  Seat  table  with  the  exception  of  Status  and  status 
date  which  comes  from  the  MAC  table  as  the  latest  status  on  the 

SeatNum  FK  provided  bv  the  session  variable. 

Actions 

Return  to  Seat  Prview  links  back  to  the  seat  preview  page. 
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4.1.2.13  Seat  Edit  Details 


W*  I*  »•» 

■  Cws-mnixmi 


o  ■  o  a  a  o]>  *  ©  s- „  « •  a  o 


SERVICE  REQUEST  EFORM 


NMCJ 


View  Seat  details  lor  NMCI  SeatID;  31596084 


Save  »n  Sew  DtW) 


Seal: 


I  eon  Si 


Asset  Location:,  fcD,IUKBt0B  |  Computer:  |  fcu,ic^Pvw 


0001AA 


Sen  CUN 

OpttooCUH  OOOME  Bate 

SubOpaonCUN  001 »  C *t 

NMOISc*®  3140M84  State 

CUiabcMioB  utxl.i4to.it  2H>Csd 

Seme.  Suit  Dm  U10I200)  BuUnitl 

SfnvtfErttiD.tr  ItlOTiOOf  Floor 

UIC  oil  w  Room  Ni 

IT  Mod#  MOOU  Cubttic 

Meet  ‘Birr  or  'DSl-FTf  Mow  lo  charo/r  aporiphml 

Associated  Peripherals: 


Sendee  TrttNurobn  9960U3JJ 
M&T  Scnrl  Number  96M621W 
D*w  lorulei  2dSr2003 

Mniiktum  On 


Description 

This  page  allows  the  user  to  choose  data  sets  to  edit  which  are  associated 
with  a  seat.  Also  presents  a  link  to  modify  the  computer  hardware  or 
Peripheral  hardware  associated  with  a  seat.  This  allows  the  user  to  see  all 
information  about  a  particular  seat. 

Security  Group 

ACTR,  DCTR 

Data 

Information  for  fields  comes  from  TbISeat  and  TbIHardware  for  the 
SeatNumber  specified  in  the  QueryStrinq. 

Actions 

Select  to  edit  the  seat,  location,  computer,  or  Add/edit/delete  a  peripheral. 
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4.1.2.14  Administrative  Seat  Edit 


y  U*  9-.  '*-**'  I—  a*  0*0  fi  y1'  -it  e  '  *  ■  ,00 

-3'*  4lK»//i3i  uoi3vwf**a<*NMCUi««  •dt.socuwwibo-iiwo 


Service  Request  eForm 


Edit  NMCI  SeatID:  75718027 

Tfcis  tufff  Wit  tAv  Hkret  ml  in  your  nut  inumrory,  fcuf  wilt  MOT  wbmil  a  nquml  to  NMCI 


Seat  CUM 

OOOIAA  v 

OptxwCUN 

S*-k>ci  Bn  Option  (mil  iwpiM)  *  WKis  n  dir  opoon  CUN’ 

SufcOpBoaCUM 

'.  elect  a  Sub  O ptinn  (onann ol l  v  Whir  u  the  Sub-Oofion  CLIN? 

NMCI  Seat  ID 

(7&718027 

8  Dints  Haw  do  I  Sn4  till!? 

CUKficaneo 

unclaitiaeti  v 

Service  Stan  Date 

tt/2Q/2002 

_J3 

Service  End  Date 

41/20/20117 

_J3 

1  SovvOongetwSaet 

1 1  OearFwm  | 

|  Concvi  Edit  | 

_ C  • 


Description 

This  screen  allows  a  user  to  edit  the  seat  CUN  and  seat  ID 
administratively.  The  changes  on  this  page  will  not  generate  a  request  to 
NMCI.  This  feature  would  be  disabled  when  the  initial  database  is 
completely  populated  with  correct  data. 

Security  Group 

ACTR,  DCTR 

Data 

All  fields  are  from  the  TbISeat 

Actions 

User  can  edit  all  fields  and  save  changes  to  the  TbISeat. 
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4.1.2.15  Seat  Location  Edit 

'>  i*  .00  ^ 


**»"■  1 1]  _  * :  Q  <* 


Service  Request  eForm 

Nffl 

Edit  the  Seat  Location  for  NMCI  SeatID:  50813032 

ITii*  Hat  a  anpfietf  to  thofellounnf  physical  location: 

SmiCUH 

0001AB 

Opt.™  CLIN 

OOIOAD 

SubOpBanCUN 

0023 

NMCI  Sut  ID 

5081 3032 

CtouiScMua 

Asset  Location: 

Addins 

but 

NRVTUB2IB  v 

C«y 

Woweown 

State 

NmrYork 

ZIP  Cede 

13801-0247  9WH-99W] 

Buddng* 

Fleet 

11 

Been)  Number 

[* 

Cubicle 

F 

<J«H _ «  H<TW 


Description 

This  screen  allows  a  user  to  edit  the  seat  location  administratively.  The 
changes  on  this  page  will  not  generate  a  request  to  NMCI.  This  feature 
would  be  disabled  when  the  initial  database  is  completely  populated  with 
correct  data. 

Security  Group 

ACTR,  DCTR 

Data 

All  fields  are  from  the  TbISeat 

Actions 

User  can  edit  all  fields  and  save  changes  to  the  TbISeat. 
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4.1.2.16  Edit  Computer 


!»  ......  imo*  o*o  3  i  t&  P  it  6  *# 

•  *)  Mw  j/t  jit®  i  ro  nt»amiJ»«  «*  r**-.« 


service  Request  eForm 


E  0 


mg  ^ 


Edit  Computer  associated  with  Seat:  31596084 

Ui*  this  dialog  to  makt  administrative  changes  to  this  computer.  Select  Save  to  commit  the  changes. 


Computer: 

NMCI  Asset  ID 
Computer  N*nw 
Service  Teg  Number 
Mfrr  Seiul  Number 
Tim  IneuOrJ 
Manu£umrer 
Install  Notre 


I96497S45A  10  Dtps  tlow  do  1  find  las? 

Serv«ifl322  The  computer's  name  on  the  network  HiatjfcjJJinsljhst? 

090046322  The  (trace  tag  associated  with  the  computer  How  do !  find  that7 

966462164 

2226/2001  j  MMDTirrrrr 

{DM  J 

Opbonei  date  you  may  weul  to  store  about  tbs  computer 


|^_S^^Uw2U»to_Caritpu]ot__J  [  Clops  Toon  ] 


_ t 


Description 

This  screen  allows  a  user  to  edit  the  computer  information  (seivice  tag 
numbers,  serial  numbers  etc. )  for  a  valid  seat.  The  changes  on  this  page 
will  not  generate  a  request  to  NMCI.  This  feature  would  be  disabled  when 
the  initial  database  is  completely  populated  with  correct  data. 

Security  Group 

ACTR,  DCTR 

Data 

Fields  come  from  TbIFIardware  base  on  the  querystring  of  seat  selected 
from  the  previous  paqe. 

Actions 

ACTR  can  change  any  field  and  submit  the  changes.  Page  returns  to  seat 
review  with  the  seat  number  as  a  querystring. 
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4.1.2.17  Add  Peripheral 

n.uuni,..ii.i.n.ni.i.ii...»..i'ii.i  Ji  n  ..  i  ,,j 

y  y  9-  't-*-  v*  m  O'Ol*lLKifS'>-A‘€>0-'i^-wEG  Tl 


-)>•  4)  NtsJ/iJt  UDittwAwaW^-icuiwr  *M  r«4M>«  *  flco 
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4.1.2.18  Edit  Peripheral 
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4.1.2.19  Peripheral  Deletion 


w  i*  »•" 't-***  v*  O'  ■  ~  ,  €  L  0 

IJJ  lt6.MMaeiVv.UJMr  »««  


service  Request  eForm  ®“ 


Delete  Peripheral 

Thi;  uriH permanently  delete  the  peripheral  Mw.  Ir  (turn  no t  reorder  or  \nbmir  any  reyumtr  to  NMCt. 

|  CancalDai—  | 

Delete  Peripheral  associated  with:  sm-ora-t** 


Hardware  Type  Camera 

NMCt  Amt  ID  W878J8 

Sum*  T*r  Number  8765508 

Mb's  Smai  Number  nkwoox 

Mamdacmrer  Dell 

Model  X390 

TnoalMuwDur  6114/5001 


« 

Description 

Confirms  the  request  to  delete  a  peripheral  from  association  with  a  Seat. 

Does  not  send  any  request  to  NMCI. 

Security  Group 

ACTR,  DCTR 

Data 

TbIHardware  provides  all  of  the  fields 

Actions 

Delete  or  cancel  deletion.  Delete  deletes  the  row  in  TbIHardware 
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4.1.2.19  Administratively  Add  Seats  (for  initial  population  or  RESFOR  use  only) 


Bwg/nsr  unite  .wf»<ga»«<tji««.»««<o *[  Q  * 
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4.1.2.20  Administratively  Add  Seat  Location  (for  initial  population  or  RESFOR  use  only) 

-j-*-  •  [fllgpWW.l»i>t4Wli«iia»l««3ft«<«.t«Jw«ii>ari4g _ _ _ jffPc° 


SERVICE  REQUEST  EFORM 


m\ 


Assign  the  Seat  to  a  Location. 

This  will  asBH/ri  ihtr  %mst  you  just  crvotml  I 

StBCUN  000 1 AA 

OpbooCLIN  0004 AA 

SukOpbonCUN  00 15 AD 

NMCI  Seat  ID  W38J747 


Bing  UIC  62128. 62128 

Asset  Location: 


955  E  Mmion  St 


Romo  Number 
Cubicle 


Description 

Assiqns  the  seat  just  created  to  a  unit  and  address. 

Security  Group 

ACTR,  DCTR 

Data 

Data  describing  the  seat  comes  from  a  query  to  the  TbISeat.  Default  data 
comes  from  the  userProfile  Joined  with  the  Activities  table.  UlCs  are  only 
UlCs  that  the  ACTR  is  responsible  for. 

Actions 

Save  location  or  clear. 
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4.1.2.21  Administratively  add  seat  computer. 


!>  I*  B*" 


«  o  -  O  ii3  ✓  -it  €> 

n,  VU*V20l*XMl»*  tS 


0  0 


SERVICE  REQUEST  EFORM 


NMCJ 


Add  Hardware  (Computer)  to  the  Seat 


Seat: 

Seat  CUN 
Option  CLIN 
SufcOpoonCLIN 
NMC1  Sen  ID 
Clarc&aaon 


Asset  Location: 


OMIAA 

0006AA 

OOI5AD 

9938374? 

unclardied 


995  E  Munnn  St 
AAAV  Woodbm 


WMCI  Ajl«t  ID  I 

Computer  Name 
Service  Tag  Number 
Mfr’t  Soul  Humber 
Dale  InnaHed 
Manufacturer  [D 

Imtafl  Hotel 


City 
State 
ZIP  Coda 

Binldmg  4 
Floor 

Room  Number 
Cubicle 


10  Dusts  How  do  1  bod  Ihri 7 

The  computer*!  name  on  the  network  Ilowjio  IJndjhii ' 
lb*  remee  tag  atrociared  with  the  computer  How  i  T fin. !  rK.c ' 
The  manufacturer*!  renal  number 

MM/DD/YYYY 


Description 

Assiqns  a  computer  to  the  seat 

Security  Group 

ACTR,  DCTR 

Data 

Data  describing  the  seat  comes  from  a  query  to  the  TbISeat. 

Actions 

Input  the  computer  properties. 
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PffriM  P*?ian 


P?3£  ???!*? 


4.1 .3  Contractor  Supervisor  and  Service  Request  Maintenance  Team  (SRM  Team)  View 
4.1. 3.1  Contractor  Supervisor  Home 


Stspcn  isor  cAwijtn 


fou  Km  29  M4Ca  to  »s  %  >yn 
4  WMACt 
24  Account  MAC  • 


ft 


Acciptod  IUC. 


Description 

Allows  the  Supervisor  to  v*ew  a  list  o ( all  ponding  MAC  roquosts  By 
selecting  the  View  Details  hyperlink  for  a  spoofle  MAC.  the  supervisor  can 
view  the  specfic  details  o(  the  MAC  and  assign  It  to  a  Service  Request 
Management  (SRM)  Team  The  supervisor  also  can  view  the  status  of 
any  MAC  previously  assignod  by  ciciong  the  appropriate  hyperlnk  on  the 
summary  page  MACs  are  sorted  by  MAC  number  and  then  the  date  the 
MAC  was  submitted  The  totals  for  the  pending  Seat  and  Account  MACs 
are  dynamically  updated  as  the  teams  change  the  status  in  the  mac 

details  page 

Security  Group 

J>u£ervso^ 

Data 

All  folds  are  derived  from  TbIMAC 

Actions 

Supervisor  can  sort  by  column  heading  and  -choose  a  MAC  to  assign  to  a 
,  team 

4.1 .3.2  Supervisor  MAC  Details  Review  and  Assign 
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BtaSlfl  fora" 


P«K?1  gt43 


Supers  i»or  cStulm 


mi  * 


gffg^nfgp.j 


Account  MAC  071 


Comrund  POC 
r«m  mm 


sasrarw^ — 3 


IV.  ■nrliSinn 

ue  scripiion 

This  page  allows  the  Supervisor  to  view  the  details  of  a  MAC  selected 
from  the  Supervisor  Homo  Page.  The  Supervisor  can  assyi  a  MAC 
request  to  spocihc  teams  lay  selecting  the  team  number  from  a  list  and 
selecting  the  update  status  option  This  page  will  display  different  fields 
based  on  whether  the  MAC  Is  an  Account  or  a  Seat  MAC  Comments  can 
also  be  added  in  the  text-entry  box 

Security  Group 

Supervisor 

Data 

All  fields  aro  derived  fromTWMAC  and  the  key  Is  obtained  through  a 
session  variable  from  the  assignment  page 

Actions 

Supervisor  can  modify  the  status,  assign  a  loam  and  provide  comments 

The  page  would  interface  with  Remedy  Holp-Oesk  to  generate  trouble- 
tickets 

4.1 .3.3  Supervisor  MAC  Status  Review 
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Supervisor  eReview 


NMO 


The  following  MACs  have  been  assigned  to  Teams 

6  Seat  MACs 

7  Account  MACs 


T..m  4.. 

MAC  Type 

aw 

MAC  Submit  Dm 

IUCU...IU. 

Oah 

IwCnonii 

1 

7 

Nr—  Oi4ri 

.inrU.uf.r4 

0001  A* 

‘70200? 

6*700? 

W.Hi»c 

NAS  P»«l  l(.rkn 

C«uuu»ul2 

1 

S 

Nr-0.4r. 

uii.Uiiif.r4  OOOIAA 

520200? 

65  200? 

Hu.Lm, 

NRC  Honolulu 

1 

2 

N—  0.4*. 

ui.cU.n5r4  OOOIAA 

570200? 

65700? 

Waika* 

Hair 

I'm  o-U*  on  af 

1 

16 

Nr-  Vtm 

im>U.n5r4 

0024  AF 

52 ”200? 

65  200? 

Weikwg 

NAVTAC 

1 

1' 

Nr-  L'm 

unrU«n6r4 

002  b  \F 

57*700? 

65  200? 

Axagnrd 

NAATAC 

1 

21 

Nr-  Utrt 

uni  Utiif.r4 

0026. AF' 

6  1  200? 

6*7005 

Amglird 

NAVTAC 

8  Jam  km  au  lUnr  *lir*4y‘ 

1 

I' 

Nr-  Utrr 

umU<uf»4 

0026AF 

6-700? 

6-700? 

WorLm* 

NAVTAC 

Ton  o(nda|  orroart  MAC 

1 

28 

Nr-  Umi 

mKU.ar.r4 

0026AF 

6*  200? 

6  5700?  WerldBc 

NAVTAC 

1 

» 

Nr-  U.« 

uncU.u5r4  0026AF 

692005 

647005 

Ar.lgnril 

NAVTAC 

1 

41 

Nr-  Uirt 

nncU.nr>.4  0026 AF 

671  200? 

66  200? 

A*«*nrJ 

NAVTAC 

2 

6 

Nr-  04rt 

uiuU.u5r4  0001 All 

520200? 

5  25200? 

Alflgllrd 

NRC  Honolulu 

3 

Nr-  Oi4rt  mulnifol  OOOIAA 

520200? 

*2700? 

Aitignnl 

NAS  P...I  Halbut 

Description 

Provides  the  Supervisor  with  a  summary  view  of  all  MACs  that  were 
previously  assigned  to  a  SRM  team.  The  totals  for  the  pending  Seat  and 
Account  MACs  are  dynamically  updated  as  the  teams  change  the  status  in 
the  MAC  details  page. 

Security  Group 

Supervisor 

Data 

All  fields  are  derived  from  TbIMAC. 

Actions 

Supervisor  can  return  to  the  previous  page  and  sort  by  column  headers. 

4.1. 3.4  Contractor  Team  Home 


Team  eReview 


NMO  ^ 


Welcome  Ian.  You  have  10  MACs  open. 
3  Seat  MACs 
7  Account  MACs 


Review  MACs  Assigned  to  Team  1 


IDA.  Numb.. 

MAC  Tfyr  OllI 

MAC  iutmfl  (><t| 

Jut  in 

tmlwu m4  If  in— <r  lllcxtlon  ' 

Arw  tl.UO. 

[  7 

Nr—  Oldri  000 1AA 

520  200? 

Woikmc  NAS  FtmI  11  ubo. 

5 

Nr-  Otdrr  OOOIAA 

520700? 

Wu.  lu»| 

.NRC  H— lulu 

Drtml. 

2 

Nr-  Onln  OOOIAA 

520200? 

Wniimt 

FU«*  |  f 

f  16 

Nr-l'.r.  0026AF 

57'200? 

VV  oi  Li— s 

NAVTAC 

IT 

Nr-  lilrr  0026AF 

52*200? 

AlU(nrd 

NAVTAC 

DrtuJt 

21 

Nr-  U.n  0026AF 

6  1  200? 

\i»{jir4 

NAVTAC 

Pt'xl. 

27 

Nr-  L'.rt  0026AF 

6-2005 

Wa.Lm* 

NAVTAC 

28 

Nr-U.n  0026AF 

6*700? 

VVoiUbx 

NAVTAC 

Dr.ml. 

29 

Nr—  Umrr  0026AF 

697005 

Vll.pnrd 

NAVTAC 

t>«<«Ji 

41 

Nr.  Uirr  0026AF 

671700?  ~ 

Aiuf-rd 

NAVTAC 

Pr.uJ. 
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Description 

Provides  the  team  with  a  view  of  all  MACS  assigned  to  them  by  the 
Supervisor  By  selecting  the  View  Details  hyperlink  (or  a  specific  MAC,  the 
team  can  view  the  specific  details  of  the  MAC.  update  the  MAC  status  and 
input  comments  Any  MAC  status  updates  submitted  by  the  foam  will 
automabcaty  update  tho  status  in  the  Supervisor's  MAC  Status  Roviow 
page  Tho  tots  Is  for  the  pending  Seat  and  Account  MACs  a  re  dyna  mically 
updated  as  the  team  changes  the  status  in  tho  MAC  defats  page 

Security  Group 

Team 

Data 

All  fields  ere  from  TblMAC  Team  nianber  rs  derived  from  the  logon  cookie 
and  file  is  the  results  to  show  only  team  1  pages 

Actions 

Team  members  can  select  a  particular  MAC  to  link  to  details  page 

Selected  MAC  number  is  posted  to  tho  do  taka  page  with 

4.1 .3.5  Contractor  Team  MAC  Details  Review  and  Assign 
Team  cStaltte  •—  WJ) 


mbb  m  J 


Ac<ouni  MAC  *71 

S—  TJH  -•*- 


Description 

Tho  page  allows  tho  Team  to  view  the  detaib  ot  a  MAC  selected  from  the 
Team  Home  Page  The  Team  can  update  the  MAC  status  from  assigned 
to  working  and  eompteto  Common!*  can  also  bo  added  n  the  to*t-ontry 
box  Any  MAC  status  updates  submitted  by  the  team  will  automatically 
update  the  status  in  the  Supervisor  s  MAC  Status  Review  page 

Secunty  Group 

Team 

Data 

Doscnbo  each  field  on  tho  screen  and  how  t  a  dorivod 

Actions 

Describe  each  action  that  can  bo  performed  from  this  screen  This  usually 
hvolves  command  buttons.,  monu  items,  etc 

4.1 .4.1  Shuffle  Function 

ThB  page  shews  only  'Processing  Roquest  Linking  accounts  te  seats  .* 
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4.1. 5.1  HELP  Active  Directory 

.>  i*  ■*— •-  »*>*  o  o  flr 

**"-•  _ _ _ *•  £J  Co 


Mappuig  to  Active  Dttetroty 

TV  foDowiryt  etepe  show  how  to  mop  to  tV  Actevr  Directory  Mapping  to  Acme  Drectory  a  snperamr  because  it  list*  the  accounts  Uut  the  contractor  show  acme  at  yote  domain,  and  ctm  therefore  bill  for  any  accounts  that 
exceed  die  total  real-to -account  tan*  audionced  at  your  locatK*  Dee  the  account!  that  are  nuible  m  Acme  Directory  to  venfr  all  bdlng  ctatementa 

1)  Locale  "My  Network  Places"  on  your  derktcp 

2)  Double-Click  the  "My  Netwwk  Plaiee"  kou 

3)  Douhk  Chck  -Enter  Netwoek' 

4)  Double  Oidc  TVeetoty 
il  Double-Click  "NA DS" 

«)  Double-Cldc  -HADSUS WE- 

7)  Double -CVfc  TJAVKESFOr 

8)  Locale  your  NBA  and  double-tkk  it 


NMCI  ACTIVE  DIRECTORY  FLOW  CHART 


«  mam* 

Description 

This  page  show  how  an  ACTR  can  map  a  drive  and  see  their  active 

directory  accounts. 

Security  Group 

ACTR,  DCTR 

Data 

Static  paqe 

Actions 

None.  Information  only. 
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4. 1.5.2  Help  Asset  ID 


1*  l*  »•»  u*  0*0  l!J  L?5  fi 


0  0 


S’ 


Ci^« _ •  I"W 


Description 

View  a  picture  of  whereto  find  asset  ID  and  Service  Taq  number. 

Security  Group 

ACTR,  DCTR 

Data 

None. 

Actions 

None. 
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4.1. 5.3  Help  Computer  Name 


Description 

View  a  picture  of  whereto  find  the  Computer  Name. 

Security  Group 

ACTR,  DCTR 

Data 

None. 

Actions 

None. 
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4. 1.5.4  Help  Seat  ID 


•>  i*  *•-  'r~"“  9 

a»>—  Ci^iiji.ia.ttt.w»c8iiw<u>«wviih>wi^ii>i^itiitm _ _ _ _ «•  flfio 


SeatID 

A  SeatID  a  a  un^ic  Rght  (Si  •iff  number  asnj»ed  to  each  teat  that  u  entered  mo  the  NET  database  Every  arret  that  a  considered  a  seat  at  MET  ta  aistped  a  SeatID  Penpheralr  that  an  attached  to  a  teat  do  not  have  iti 
own  SeatID  If  a  peripheral  is  ordered  as  a  seat  Man  ialooe)  then  tf  would  have  its  own  SeatID 


Description 

View  a  picture  of  where  to  find  NMCI  Seat  ID. 

Security  Group 

ACTR,  DCTR 

Data 

None. 

Actions 

None. 
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4.2  Reports 

4.2.1  Report  RESFOR  Statistics. 


(3-  o 

(]ku 


ii  <1  PA© 


0  0 


BdUifl 

* 

-  a» 


Service  Request  eForm 

RESFOR  STATISTICS  PAGE 

ne  following  Hotlines  are  as  of  the  Ian  Shuffle  of  free  accounts  and  scan. 

'lb  update  this  data  press  Shuffle . 

This  process  will  take  opproximatalu  I.. 5  minutes  to  complete. 

ACCOUNT  TO  SEAT  AUDIT 

Total  Non-Billable  Accounts:  0 

Total  Billable  Accounts:  64728 

Total  Free  Accounts  Derived  from  Seats  (unclassifed):  43S39 

Free  Accounts  Unoccupied:  0 

CLIN  24's  needed:  21189 

SEAT  AUDIT 

Total  Installed  Seats  39664 

Seats  Awaiting  Install  37 

Description 

The  report  provides  the  RESFOR  CTR  with  statistical  Account  and  Seat 
statistical  information.  The  information  is  automatically  updated  on  a 
scheduled  basis  by  use  of  the  shuffle  application.  The  user  may  manually 
execute  the  shuffle  application  to  view  current  data. 

Security  Group 

RESFOR 

Data 

Non-billable  accounts  are  those  in  Disabled  or  Pending  status  in  the 
UserProfile  table. 

Total  Billable  accounts  are  not  in  disabled  or  pending. 

Total  Free  Accounts  derived  from  seats  is  the  row  count  ofTblAccounts 

Free  Accounts  unoccupied  is  the  count  of  rows  in  TbIAccounts  where 
UserNum  is  Null. 

CLIN'24s  will  either  be  zero  if  Free  Accounts  Unoccupied  >  0  or  this  will  be 
Billable  accounts  -  Seats. 

Installed  seats  is  the  number  of  rows  where  Status  =  Installed 

Installed  seats  is  the  number  where  Status  does  not  =  Returned,  Rejected 
or  Installed. 

Groupings 

This  is  a  numerical  report. 

Totals 

See  Data  description 

Filters 

None. 

Export  Formats 

Printer  through  IE  or  data  may  be  captured  and  stored  in  a  historical  table 
not  present  in  this  prototype. 

Freguencv 

Shuffle  function  should  be  executed  after  COB  for  last  time  zones  daily. 
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Historical  information  can  be  written  to  a  row  nightly.  Report  can  be 
viewed  on  demand  and  updated  on  demand. _ 


5.  Business  Layer 

Define  all  of  the  objects  necessary  to  support  the  presentation  layer.  First  show  the  object 
hierarchy  then  include  the  Microsoft  Visual  Modeler  file  that  shows  the  details  as  Appendix  A. 


6.  Database  Layer 


Appendix  B  contains  a  detailed  description  of  the  attributes  associated  with  each  field,  table  and 


view used  to  support  this  application 


it,.-  _Fi 
MFTTO 

MUQhnMD 

jeroce  I  agFAmber 

pen»«i*nb«r 

DesA/ymwrtDal* 

HadwMTypa 

Irtvitvi  rn 
n«M 

L'StJttXK 


7.  Other  Design  Considerations 


7.1  Conversion  Modules 

Server  2003  Active  Directory  can  export  to  a  Microsoft  Database  format  and  vice-versa. 
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3.1 .3.3  Search  MAC  Account  History 

4. 1.1. 7  Accounts  within  a  specific  ACTR’sUIC 

4.1 .1 .8  Account  Details 

4.1. 2.3  ACTR  Home 

3.1 .3.4  Order  a  new  seat 

4.1 .1 .1  In-Process  new  users-  Search  Accounts  for 
Profile 

4.1 .1 .2  In-Process  new  users  “Search  Results” 

4.1 .1 .4  User  MAC  History 

4. 1.2.4  Order  a  hardware  seat 

3.1 .3.4. a 

4.1 .2.5  Order  Review 

3.1 .3.4. b 

4. 1.2. 7  Seat_Review 

3.1 .3.4. c 

4.1 .2.12  Seat  Details  for  pending  seat 

3.1 .3.5  Request  an  Upgrade  to  an  existing  seat 

4.1 .2.8  Seat  Selection 

3.1 .3 .5. a 

4.1 .2.9  Seat  Upgrade 

3.1 .3.5. b 

3.1 .3.6  Request  a  Physical  Seat  Move 

4.1 .2.8  Seat  Selection 

3.1 .3. 6. a 

4.1 .2.10  Request  Seat  Move 

3.1 .3.7  Turn  in  any  excess  seats 

4.1 .2.8  Seat  Selection 

3.1 .3.7. a 

4.1.2.11  SeatTum-in 

3.1 .3.8  View/Edit  Seat  Data 

4.1 .2.7  Seat_Review 

3.1 .3. 8. a 

4.1 .2.13  Seat  Edit  Details 

3.1 .3.9  View/Edit  Hardware  and  peripherals 

4.1 .2.14  Administrative  Seat  Edit 

4.1 .2.16  Edit  Computer 

4.1 .2.15  Edit  Seat  Location 

4. 1.2. 7  Seat_Review 

3.1 .3 .9. a 

4.1 .2.13  Seat  Edit  Details 
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3.1.3.10  Validate  eMarketplace  Invoice 

3.1.3.11  Administratively  Add  Seats 

3.1. 3.11. a 

3.1 .3.1 1  .b 

3.1 .3.1 1  c 

3.1 .3.1 1  .d 

3.1 .3.1 1  e 

3.1 .3.1 1  f 

4.1 .2.14  Administrative  Seat  Edit 

4.1 .2.16  Edit  Computer 

4.1 .2.15  Edit  Seat  Location 

4.1 .2.7  Seat_Review 

4.1 .2.20  Administratively  Add  Seat 

4.1 .2.21  Administratively  Add  Seat  Location 

4.1 .2.22  Administratively  add  seat  computer 

4.1.2.17  Add  Peripheral 

4.1 .2.13  Seat  Edit  Details 

4.1 .2.7  Seat_Review 

3.1.4  DCTR 

3. 1.4  .a 

3.1 .4.  b 

3.1.4. C 

4.1 .2.3  ACTR  Home 

4.1 .1.9  DCTR  Home 

4.1 .1 .10  DCTR  MAC  Seat  Order  Review 

4.1 .1 .1 1  DCTR  MAC  Account  Order  Review 

4.1.1.12 

3.1 .5  Contractor  Management 

3.1. 5  .a 

4. 1.3.1  Contractor  Supervisor  Home 

4.1 .3.4  Contractor  Team  Home 

3. 1.5.1  Contractor  Supervisor 

3.1. 5.1  .a 

3.1. 5.1  .b 

3.1 .5.1  .c 

3.1 .5.1  d 

4. 1.3.1  Contractor  Supervisor  Home 

4.1 .3.2  Supervisor  MAC  Details  Review  and  Assign 

4.1 .3.3  Supervisor  MAC  Status  Review 

3.1 .5.2  Contractor  SRM  Team 

3.1 .5 .2.  a 

3.1 .5.2.  b 

3.1 .5.2.  c 

4.1 .3.4  Contractor  Team  Home 

4. 1.3. 3  Contractor  Team  MAC  Details  Review  and 
Assign 

3.1.6  RESFOR  Management 

3.1. 6.a 

4.2.1  Report  RESFOR  Statistics 

4.1 .4.1  Shuffle  Application. 
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